RE: [PATCH] devfreq: Make log message more explicit when devfreq device already exists

dev_err(dev, "%s: Unable to create devfreq for the device.\n", >+ dev_err(dev, "%s: devfreq device already exists!\n", Yes, this is more helpful! Thanks! Acked-by: MyungJoo Ham

Re: linux-next: build warning after merge of the devfreq tree

e.c:152:17: warning: unused variable 'dev' > [-Wunused-variable] > struct device *dev = devfreq->dev.parent; > ^~~ > > Introduced by commit > > 0ef7c7cce43f ("PM / devfreq: passive: Use non-devm notifiers") > > -- > Cheers, > Stephen Rothwell -- MyungJoo Ham, Ph.D. S/W Center, Samsung Electronics

[PATCH] PM / devfreq: passive: fix compiler warning

The recent commit of PM / devfreq: passive: Use non-devm notifiers had incurred compiler warning, "unused variable 'dev'". Reported-by: Stephen Rothwell Signed-off-by: MyungJoo Ham --- drivers/devfreq/governor_passive.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drive

RE: Re: [PATCH] devfreq: tegra20: add COMMON_CLK dependency

0 DEVFREQ Driver" > depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST > + depends on COMMON_CLK > select DEVFREQ_GOV_SIMPLE_ONDEMAND > select PM_OPP > help > Acked-by: MyungJoo Ham Thanks! Cheers, MyungJoo.

RE: [PATCH v3 02/22] PM / devfreq: tegra30: Keep interrupt disabled while governor is stopped

>There is no real need to keep interrupt always-enabled, will be nicer >to keep it disabled while governor is inactive. > >Suggested-by: Thierry Reding >Signed-off-by: Dmitry Osipenko >--- > drivers/devfreq/tegra30-devfreq.c | 43 --- > 1 file changed, 22

RE: [PATCH v2 4/4] PM / devfreq: Add required OPPs support to passive governor

>Signed-off-by: Saravana Kannan >--- > drivers/devfreq/governor_passive.c | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) Acked-by: MyungJoo Ham Cheers, MyungJoo

RE: [PATCH v2 3/4] PM / devfreq: Cache OPP table reference in devfreq

>The OPP table can be used often in devfreq. Trying to get it each time can >be expensive, so cache it in the devfreq struct. > >Signed-off-by: Saravana Kannan >--- > drivers/devfreq/devfreq.c | 6 ++ > include/linux/devfreq.h | 1 + > 2 files changed, 7 insertions(+)

RE: Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30

Sender : Dmitry Osipenko >24.06.2019 14:11, MyungJoo Ham пишет: >>> >>> - Original Message - >>> Sender : Dmitry Osipenko >>> >>> 24.06.2019 10:34, MyungJoo Ham пишет: >>>>> >>>>> A question: >&

RE: Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30

> >- Original Message - >Sender : Dmitry Osipenko > >24.06.2019 10:34, MyungJoo Ham пишет: >>> >>> A question: >>> >>> Does this driver support Tegra20 as well? >>> I'm asking this because ARCH_TEGRA includes A

Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30

> >A question: > >Does this driver support Tegra20 as well? >I'm asking this because ARCH_TEGRA includes ARCH_TEGRA_2x_SOC >according to /drivers/soc/tegra/Kconfig. > For this matter, how about updating your 13/16 patch as follows? --- drivers/devfreq/Kconfig | 4 ++--

Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30

> On Thu, May 02, 2019 at 02:38:12AM +0300, Dmitry Osipenko wrote: > > The devfreq driver can be used on Tegra30 without any code change and > > it works perfectly fine, the default Tegra124 parameters are good enough > > for Tegra30. > > > > Reviewed-by: Chanwoo Choi > > Signed-off-by: Dmitry

RE: [PATCH v1 01/11] PM / devfreq: tegra30: Change irq type to unsigned int

>IRQ numbers are always positive, hence the corresponding variable should >be unsigned to keep types consistent. This is a minor change that cleans >up code a tad more. > >Suggested-by: Thierry Reding >Signed-off-by: Dmitry Osipenko Acked-by: MyungJoo Ham Cheers, MyungJoo

RE: [PATCH v2 4/4] devfreq: add mediatek cci devfreq

>This adds a devfreq driver for the Cache Coherent Interconnect (CCI) >of the Mediatek MT8183. > >On the MT8183 the CCI is supplied by the same regulator as the LITTLE >cores. The driver is notified when the regulator voltage changes >(driven by cpufreq) and adjusts the CCI frequency to the

RE: [PATCH v2 2/4] opp: add API which get max freq by voltage

>This API will get voltage as input parameter. >Search all opp items for the item which with max frequency, >and the voltae is smaller than provided voltage. > >Signed-off-by: Andrew-sh.Cheng >--- > drivers/opp/core.c | 55 ++ >

RE: [PATCH v3 3/5] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.

e termination (ODT) disable frequency >this driver should disable the DDR ODT. > >Signed-off-by: Enric Balletbo i Serra >Reviewed-by: Chanwoo Choi >Signed-off-by: Gael PORTAY Acked-by: MyungJoo Ham Cheers! MyungJoo >--- > >Changes in v3: >- [PATCH v2 3/5] Add Signed-

RE: [PATCH v3 2/5] dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle.

t; Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: MyungJoo Ham

RE: [PATCH v3 1/5] devfreq: rockchip-dfi: Move GRF definitions to a common place.

dfi.c | 23 +++ > include/soc/rockchip/rk3399_grf.h| 21 + > 2 files changed, 28 insertions(+), 16 deletions(-) > create mode 100644 include/soc/rockchip/rk3399_grf.h > Acked-by: MyungJoo Ham

RE: Re: [PATCH] PM / devfreq: exynos-bus: Suspend all devices on system shutdown

@@ MODULE_DEVICE_TABLE(of, exynos_bus_of_match); >>> >>> static struct platform_driver exynos_bus_platdrv = { >>> .probe = exynos_bus_probe, >>> + .shutdown = exynos_bus_shutdown, >>> .driver = { >>> .name = "exynos-bus", >>> .pm = _bus_pm, >>> >> Actually, I already agreed the previous patch. >> Also, it looks good to me. > >Yes, I know, but MyungJoo had some objections, that's why I prepared >alternative version. > >> Acked-by: Chanwoo Choi >> This has become looking good now :) Acked-by: MyungJoo Ham Cheers, MyungJoo

RE: [RESEND PATCH] PM / devfreq: Fix static checker warning in try_then_request_governor

ilt as modules.") >Reported-by: Dan Carpenter >Signed-off-by: Enric Balletbo i Serra >Reviewed-by: Chanwoo Choi >--- >Hi, > >This is a resend of [1] as seems that got lost at some point and I just >noticed that was never merged. > >Thanks, > Enric Acked-by: MyungJoo Ham Thanks! CHeers, MyungJoo

RE: [PATCH v5] PM / devfreq: Restart previous governor if new governor fails to start

__func__, df->governor_name, ret); >+ df->governor = NULL; >+ } Acked-by: MyungJoo Ham >--- >V5: >* assume fatal on revert failure and set df->governor to NULL > >V4: >* Removed prev_governor check. > >V3: >* Fix N

RE: Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start

>Hey MyungJoo, Kyungmin >Did you get a chance to think about how you >want this fix implemented? > >On 2019-02-19 10:42, Sibi Sankar wrote: >> Hey MyungJoo, >> >> On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>>> From: Saravana Kannan >>>> &g

RE: Re: [PATCH v3 5/7] drivers: devfreq: add longer polling interval in idle

>> >> There are some requirements that you need to consider: >> >> Is 30% really applicable to ALL devfreq devices? >The 30% load while the device is on lowest OPP is to filter some noise. >It might be tunable over sysfs for each device if you like. >> - What if some devices do not want

RE: [PATCH v3 2/2] drivers: devfreq: add tracing for scheduling work

drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c >index 0ae3de7..660365a 100644 >--- a/drivers/devfreq/devfreq.c >+++ b/drivers/devfreq/devfreq.c Acked-by: MyungJoo Ham

RE: [PATCH v3 1/2] trace: events: add devfreq trace event file

| 1 + > include/trace/events/devfreq.h | 40 > 2 files changed, 41 insertions(+) > create mode 100644 include/trace/events/devfreq.h Acked-by: MyungJoo Ham Thanks! Cheers, MyungJoo

Re: [PATCH 3/3] PM / devfreq: tegra: remove unneeded variable

e DEVFREQ_GOV_START: > >> @@ -600,7 +597,7 @@ static int tegra_governor_event_handler(struct devfreq > >> *devfreq, > >> break; > >> } > >> > >> -return ret; > >> +return 0; > >> } > >> > >> static struct devfreq_governor tegra_devfreq_governor = { > >> > > > > Reviewed-by: Chanwoo Choi > > > > Acked-by: Jon Hunter > > Thanks! > Jon Acked-by: MyungJoo Ham Merged. Thanks! > > -- > nvpublic -- MyungJoo Ham, Ph.D. S/W Center, Samsung Electronics

Re: [PATCH 1/3] PM / devfreq: rk3399_dmc: remove unneeded semicolon

@ -322,7 +322,7 @@ static int rk3399_dmcfreq_probe(struct platform_device > > *pdev) > > > > dev_err(dev, "Cannot get the clk dmc_clk\n"); > > return PTR_ERR(data->dmc_clk); > > - }; > > + } > > > > data->ede

Re: [PATCH 2/3] PM / devfreq: rockchip-dfi: remove unneeded semicolon

RR(data->clk); > > - }; > > + } > > > > /* try to find the optional reference to the pmu syscon */ > > node = of_parse_phandle(np, "rockchip,pmu", 0); > > > > Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham Merged. Thanks. > > -- > Best Regards, > Chanwoo Choi > Samsung Electronics -- MyungJoo Ham, Ph.D. S/W Center, Samsung Electronics

RE: [PATCH v3 5/7] drivers: devfreq: add longer polling interval in idle

> This patch adds new mechanism for devfreq devices which changes polling > interval. The system should sleep longer when the devfreq device is almost > not used. The devfreq framework will not schedule the work too often. > This low-load state is recognised when the device is operating at the

RE: [PATCH 3/3] devfreq: add mediatek cci devfreq

>From: "Andrew-sh.Cheng" > >For big/little cpu cluster architecture, >not only CPU frequency, but CCI frequency will also affect performance. > >Little cores and cci share the same buck in Mediatek mt8183 IC, >so we add a CCI devfreq which will get notification when buck voltage >is changed, then

RE: [PATCH] devfreq: Suspend all devices on system shutdown

>This way devfreq core ensures that all its devices will be set to safe >operation points before reboot operation. There are board on which some >aggressive power saving operation points are behind the capabilities of >the bootloader to properly reset the hardware and boot the board. This >way one

RE: Re: [PATCH] drivers: extcon: Add support for ptn5150

>Hi Chanwoo Choi, > >This is the first time I am sending a driver to LKML. I have a few doubts. Can >you please clarify them when you are free? Although I'm not Chanwoo, but a guy who's about 50ft away from his cubicle, as he appears to be busy today... :) > >1. I have developed and tested this

[PATCH] PM / devfreq: consistent indentation

-by: MyungJoo Ham --- drivers/devfreq/devfreq.c | 49 +++ 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 4af608a..428a1de 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq

RE: [PATCH 2/3] PM / devfreq: fix missing check of return value in devfreq_add_device()

devfreq.c b/drivers/devfreq/devfreq.c >index 076b1c2f40a4..923889229a0b 100644 >--- a/drivers/devfreq/devfreq.c >+++ b/drivers/devfreq/devfreq.c Acked-by: MyungJoo Ham

RE: [PATCH 3/3] PM / devfreq: fix mem leak in devfreq_add_device()

>'devfreq' is malloced in devfreq_add_device() and should be freed in >the error handling cases, otherwise it will cause memory leak. > >Signed-off-by: Yangtao Li Acked-by: MyungJoo Ham >--- > drivers/devfreq/devfreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 dele

RE: [PATCH] PM / devfreq: fix mem leak and missing check of return value in devfreq_add_device()

> 'devfreq' is malloced in devfreq_add_device() and should be freed in > the error handling cases, otherwise it will cause memory leak. > > devm_kzalloc() could fail, so insert a check of its return value. And > if it fails, returns -ENOMEM. > > Signed-off-by: Yangtao Li Dear Yangtao, Could

RE: Re: [PATCH v3 4/5] drivers: power: suspend: call devfreq suspend/resume

eviewed-by: Chanwoo Choi >> Signed-off-by: Lukasz Luba This looks all good to me. Acked-by: MyungJoo Ham >> --- >> drivers/base/power/main.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c &

Re: [PATCH] devfreq: Use of_node_name_eq for node name comparisons

sitive comparisons. This should not matter for any FDT based > system which all of these are. > > Cc: Chanwoo Choi > Cc: MyungJoo Ham > Cc: Kyungmin Park > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: linux...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradea

RE: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start

> From: Saravana Kannan > > If the new governor fails to start, switch back to old governor so that the > devfreq state is not left in some weird limbo. > > Signed-off-by: Sibi Sankar > Signed-off-by: Saravana Kannan > Reviewed-by: Chanwoo Choi Hello, In overall, the idea and the

RE: Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

> Hi Saravana, > > The devfreq git repo is maintained by Myungjoo Ham. > you can check it on MAINTAINERS file. > > I think that you better to resend mail to mainline > with my reviewed tag because the devfreq core could be modified > and then merge conflict might be happ

RE: Re: [PATCH v3 3/5] devfreq: add devfreq_suspend/resume() functions

oo Choi > > Signed-off-by: Lukasz Luba > > --- > > drivers/devfreq/devfreq.c | 44 > > include/linux/devfreq.h | 6 ++ > > 2 files changed, 50 insertions(+) > > Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham

RE: [PATCH v3 1/5] devfreq: refactor set_target frequency function

ukasz Luba > --- Acked-by: MyungJoo Ham

RE: Re: [PATCH v3 2/5] devfreq: add support for suspend/resume of a devfreq device

ff-by: Lukasz Luba > > --- > > drivers/devfreq/devfreq.c | 47 > > +-- > > include/linux/devfreq.h | 7 +++ > > 2 files changed, 48 insertions(+), 6 deletions(-) > > Reviewed-by: Chanwoo Choi > Looks goot do me as well. Acked-by: MyungJoo Ham

RE: [PATCH 1/6] devfreq: add basic fileds supporting suspend functionality

>The patch prepares devfreq device for handling suspend/resume functionality. >The new fields will store needed information during this process. >Devfreq framework handles opp-suspend DT entry and there is no need of >modyfications in the drivers code. > >The patch draws on Tobias Jakobi's work

RE: [PATCH 1/6] devfreq: add basic fileds supporting suspend functionality

>The patch prepares devfreq device for handling suspend/resume functionality. >The new fields will store needed information during this process. >Devfreq framework handles opp-suspend DT entry and there is no need of >modyfications in the drivers code. > >The patch draws on Tobias Jakobi's work

RE: [PATCH v2] PM / devfreq: Stop the governor before device_unregister()

eondemand which is using the devfreq deferrable monitoring work. If it > is not stopped before the resources are freed, it might lead to a use after > free. > > Signed-off-by: Vincent Donnefort > Reviewed-by: John Einar Reitan > Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham Cheers, MyungJoo

RE: [PATCH v2] PM / devfreq: Stop the governor before device_unregister()

eondemand which is using the devfreq deferrable monitoring work. If it > is not stopped before the resources are freed, it might lead to a use after > free. > > Signed-off-by: Vincent Donnefort > Reviewed-by: John Einar Reitan > Reviewed-by: Chanwoo Choi Acked-by: MyungJoo Ham Cheers, MyungJoo

RE: [PATCH] PM / devfreq: remove redundant null pointer check before kfree

  > kfree has taken the null pointer into account. hence it is safe > to remove the redundant null pointer check before kfree. > > Signed-off-by: zhong jiang Acked-by: MyungJoo Ham > --- > drivers/devfreq/devfreq.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletio

RE: [PATCH] PM / devfreq: remove redundant null pointer check before kfree

  > kfree has taken the null pointer into account. hence it is safe > to remove the redundant null pointer check before kfree. > > Signed-off-by: zhong jiang Acked-by: MyungJoo Ham > --- > drivers/devfreq/devfreq.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletio

RE: Re: [PATCH] devfreq: Convert to using %pOFn instead of device_node.name

> Dear Rob, > > On 2018년 08월 28일 10:52, Rob Herring wrote: > > In preparation to remove the node name pointer from struct device_node, > > convert printf users to use the %pOFn format specifier. > > > > Cc: Chanwoo Choi > > Cc: MyungJoo Ham > >

RE: Re: [PATCH] devfreq: Convert to using %pOFn instead of device_node.name

> Dear Rob, > > On 2018년 08월 28일 10:52, Rob Herring wrote: > > In preparation to remove the node name pointer from struct device_node, > > convert printf users to use the %pOFn format specifier. > > > > Cc: Chanwoo Choi > > Cc: MyungJoo Ham > >

RE: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

>This driver registers itself as a devfreq device that allows devfreq >governors to make bandwidth votes for an interconnect path. This allows >applying various policies for different interconnect paths using devfreq >governors. > First of all, the name, "devfreq_icbw", is not appropriate for a

RE: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

>This driver registers itself as a devfreq device that allows devfreq >governors to make bandwidth votes for an interconnect path. This allows >applying various policies for different interconnect paths using devfreq >governors. > First of all, the name, "devfreq_icbw", is not appropriate for a

RE: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch adds a

RE: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch adds a

RE: Re: Re: devfreq relation with pm qos

>MyungJo, I am trying to understand the relationship of PM QOS with >devfreq drivers. I don't see any relation of PM QOS api's with devfreq drivers >directly as there are no QOS apis used in the devfreq framework. > >The only explanation I have is that PM QOS has direct relationship >with CPUFREQ

RE: Re: Re: devfreq relation with pm qos

>MyungJo, I am trying to understand the relationship of PM QOS with >devfreq drivers. I don't see any relation of PM QOS api's with devfreq drivers >directly as there are no QOS apis used in the devfreq framework. > >The only explanation I have is that PM QOS has direct relationship >with CPUFREQ

RE: Re: devfreq relation with pm qos

> + dev freq maintainters. > > On Mon, Jul 9, 2018 at 3:37 AM, noman pouigt wrote: > > folks, > > > > I am trying to figure out the relationship between PM QOS > > with devfreq framework. I see this thread[1] where MyungJoo > > talks about QOS and devfreq but that control is through > > sysfs

RE: Re: devfreq relation with pm qos

> + dev freq maintainters. > > On Mon, Jul 9, 2018 at 3:37 AM, noman pouigt wrote: > > folks, > > > > I am trying to figure out the relationship between PM QOS > > with devfreq framework. I see this thread[1] where MyungJoo > > talks about QOS and devfreq but that control is through > > sysfs

RE: [PATCH v5 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa

wed-by: Brian Norris >--- >Changes in v5: >- none > >Changes in v4: >- added 'Reviewed-by: Brian Norris ' tag > >Changes in v3: >- none > >Changes in v2: >- added 'Reviewed-by: Chanwoo Choi ' tag >--- > drivers/devfreq/devfreq.c | 12 ++-- > 1 fi

RE: [PATCH v5 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa

wed-by: Brian Norris >--- >Changes in v5: >- none > >Changes in v4: >- added 'Reviewed-by: Brian Norris ' tag > >Changes in v3: >- none > >Changes in v2: >- added 'Reviewed-by: Chanwoo Choi ' tag >--- > drivers/devfreq/devfreq.c | 12 ++-- > 1 fi

RE: [PATCH v4] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

>+ if (!strncmp(name, DEVFREQ_GOV_SIMPLE_ONDEMAND, >+ DEVFREQ_NAME_LEN)) >+ err = request_module("governor_%s", "simpleondemand"); >+ else >+ err = request_module("governor_%s", name); >+ if

RE: [PATCH v4] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

>+ if (!strncmp(name, DEVFREQ_GOV_SIMPLE_ONDEMAND, >+ DEVFREQ_NAME_LEN)) >+ err = request_module("governor_%s", "simpleondemand"); >+ else >+ err = request_module("governor_%s", name); >+ if

RE: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

>@@ -988,12 +1030,13 @@ static ssize_t governor_store(struct device *dev, >struct device_attribute *attr, > if (ret != 1) > return -EINVAL; > >- mutex_lock(_list_lock); >- governor = find_devfreq_governor(str_governor); >+ governor =

RE: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

>@@ -988,12 +1030,13 @@ static ssize_t governor_store(struct device *dev, >struct device_attribute *attr, > if (ret != 1) > return -EINVAL; > >- mutex_lock(_list_lock); >- governor = find_devfreq_governor(str_governor); >+ governor =

RE: Re: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

> >> Adding to Ezequiel's point, shouldn't we take more granular lock > >> (devfreq->lock) first and then call devfreq_list_lock at the time of > >> adding to the list? > >> > > > > Not sure why we should do that. devfreq->lock should be used to > > protect the struct devfreq state, while the

RE: Re: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

> >> Adding to Ezequiel's point, shouldn't we take more granular lock > >> (devfreq->lock) first and then call devfreq_list_lock at the time of > >> adding to the list? > >> > > > > Not sure why we should do that. devfreq->lock should be used to > > protect the struct devfreq state, while the

Re: [RFC] PM / devfreq: Add support for alerts

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 wrote: > > > On 5/31/2018 11:47 AM, MyungJoo Ham wrote: >>> >>> Currently, DEVFREQ reevaluates the device state periodically and/or >>> ba

Re: [RFC] PM / devfreq: Add support for alerts

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 wrote: > > > On 5/31/2018 11:47 AM, MyungJoo Ham wrote: >>> >>> Currently, DEVFREQ reevaluates the device state periodically and/or >>> ba

RE: [RFC] PM / devfreq: Add support for alerts

> 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

RE: [RFC] PM / devfreq: Add support for alerts

> 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

RE: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch series adds

RE: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch series adds

RE: [PATCH 08/11] PM / devfreq: Make update_devfreq() public

gt;--- > drivers/devfreq/governor.h | 3 --- > include/linux/devfreq.h| 8 > 2 files changed, 8 insertions(+), 3 deletions(-) With the requirement from patch 9/11, this commit is reasonable enough. Acked-by: MyungJoo Ham <myungjoo@samsung.com>

RE: [PATCH 08/11] PM / devfreq: Make update_devfreq() public

evfreq/governor.h | 3 --- > include/linux/devfreq.h| 8 > 2 files changed, 8 insertions(+), 3 deletions(-) With the requirement from patch 9/11, this commit is reasonable enough. Acked-by: MyungJoo Ham

RE: [PATCH 07/11] PM / devfreg: Add support policy notifiers

>Policy notifiers are called before a frequency change and may narrow >the min/max frequency range in devfreq_policy, which is used to adjust >the target frequency if it is beyond this range. > >Also add a few helpers: > - devfreq_verify_within_[dev_]limits() >- should be used by the notifiers

RE: [PATCH 07/11] PM / devfreg: Add support policy notifiers

>Policy notifiers are called before a frequency change and may narrow >the min/max frequency range in devfreq_policy, which is used to adjust >the target frequency if it is beyond this range. > >Also add a few helpers: > - devfreq_verify_within_[dev_]limits() >- should be used by the notifiers

RE: [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits

>The performance, powersave and simpleondemand governors can return >df->min/max_freq, which are the user defined frequency limits. >update_devfreq() already takes care of adjusting the target frequency >with the user limits if necessary, therefore we can return >df->scaling_min/max_freq instead,

RE: [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits

>The performance, powersave and simpleondemand governors can return >df->min/max_freq, which are the user defined frequency limits. >update_devfreq() already takes care of adjusting the target frequency >with the user limits if necessary, therefore we can return >df->scaling_min/max_freq instead,

RE: [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment from governors

s(-) > Yes, indeed. Governors are no longer required to be aware of min/max freq. Acked-by: MyungJoo Ham <myungjoo@samsung.com>

RE: [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment from governors

vernors are no longer required to be aware of min/max freq. Acked-by: MyungJoo Ham

RE: [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors

overnor_simpleondemand.c | 7 +++ > 2 files changed, 4 insertions(+), 8 deletions(-) > >diff --git a/drivers/devfreq/governor_performance.c >b/drivers/devfreq/governor_performance.c >index 4d23ecfbd948..1c990cb45098 100644 > Thanks! Acked-by: MyungJoo Ham <myungjoo@samsung.com>

RE: [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors

c | 7 +++ > 2 files changed, 4 insertions(+), 8 deletions(-) > >diff --git a/drivers/devfreq/governor_performance.c >b/drivers/devfreq/governor_performance.c >index 4d23ecfbd948..1c990cb45098 100644 > Thanks! Acked-by: MyungJoo Ham

RE: [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0

't be 0 the > checks for this case can be removed. > > Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") > Signed-off-by: Matthias Kaehlcke <m...@chromium.org> > --- > drivers/devfreq/devfreq.c | 30 ++ > 1 file changed, 18 insertions(+), 12 deletions(-) Thanks a lot! Nice Catch. Acked-by: MyungJoo Ham <myunngjoo@samsung.com> Cheers, MyungJoo.

RE: [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0

't be 0 the > checks for this case can be removed. > > Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") > Signed-off-by: Matthias Kaehlcke > --- > drivers/devfreq/devfreq.c | 30 ++ > 1 file changed, 18 insertions(+), 12 deletions(-) Thanks a lot! Nice Catch. Acked-by: MyungJoo Ham Cheers, MyungJoo.

RE: [PATCH v4 0/6] devfreq: rk3399_dmc: improve rk3399_dmc driver and it's documentation

>Dear all, > >These patches is an attempt to improve a little bit the rk3399_dmc >driver and it's documentation in order to have all in a better shape for >a future work I am doing. My final intention is add ddrfreq support for >rockchip drm driver, but the patches for this are still

RE: [PATCH v4 0/6] devfreq: rk3399_dmc: improve rk3399_dmc driver and it's documentation

>Dear all, > >These patches is an attempt to improve a little bit the rk3399_dmc >driver and it's documentation in order to have all in a better shape for >a future work I am doing. My final intention is add ddrfreq support for >rockchip drm driver, but the patches for this are still

RE: [PATCH v4 3/6] devfreq: rk3399_dmc: remove wait for dcf irq event.

> 1 file changed, 1 insertion(+), 52 deletions(-) > Acked-by: MyungJoo Ham <myungjoo@samsung.com>

RE: [PATCH v4 3/6] devfreq: rk3399_dmc: remove wait for dcf irq event.

ewed-by: Chanwoo Choi >--- > >Changes in v4: None >Changes in v3: None >Changes in v2: >- [3/6] Add Reviewed-by Chanwoo Choi > > drivers/devfreq/rk3399_dmc.c | 53 +--- > 1 file changed, 1 insertion(+), 52 deletions(-) > Acked-by: MyungJoo Ham

RE: [PATCH v4 6/6] devfreq: rk3399_dmc: fix spelling mistakes.

gt; > drivers/devfreq/rk3399_dmc.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Acked-by: MyungJoo Ham <myungjoo@samsung.com>

RE: [PATCH v4 6/6] devfreq: rk3399_dmc: fix spelling mistakes.

12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Acked-by: MyungJoo Ham

RE: Re: [PATCH 1/3] PM / devfreq: Actually support providing freq_table

>On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote: > >> 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

RE: Re: [PATCH 1/3] PM / devfreq: Actually support providing freq_table

>On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote: > >> 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

RE: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

>From: Lin Huang > >Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to >ensure that the pd driver and the dmc driver will not access at this >register at the same time. > >Signed-off-by: Lin Huang >Signed-off-by: Enric Balletbo i Serra

RE: [PATCH 6/6] devfreq: rk3399_dmc: register devfreq notification to dmc driver.

>From: Lin Huang > >Because dmc may also access the PMU_BUS_IDLE_REQ register, we need to >ensure that the pd driver and the dmc driver will not access at this >register at the same time. > >Signed-off-by: Lin Huang >Signed-off-by: Enric Balletbo i Serra >--- > > drivers/devfreq/rk3399_dmc.c

RE: [PATCH 5/6] devfreq: rk3399_dmc: do not print error when get supply and clk defer.

Enric Balletbo i Serra <enric.balle...@collabora.com> Acked-by: MyungJoo Ham <myungjoo@samsung.com> I'll wait for the rebase of 3/6. > --- > > drivers/devfreq/rk3399_dmc.c | 6 ++ > 1 file changed, 6 insertions(+) >

RE: [PATCH 5/6] devfreq: rk3399_dmc: do not print error when get supply and clk defer.

> From: Lin Huang > > We just return -EPROBE_DEFER error code to caller and do not > print error message when try to get center logic regulator > and DMC clock defer. > > Signed-off-by: Lin Huang > Signed-off-by: Enric Balletbo i Serra Acked-by: MyungJoo Ham I'll wa

RE: [PATCH 3/6] devfreq: rk3399_dmc: remove wait for dcf irq event.

> We have already wait dcf done in ATF, so don't need wait dcf irq > in kernel, besides, clear dcf irq in kernel will import competiton > between kernel and ATF, only handle dcf irq in ATF is a better way. > > Signed-off-by: Lin Huang > Signed-off-by: Enric Balletbo i Serra

RE: [PATCH 3/6] devfreq: rk3399_dmc: remove wait for dcf irq event.

> We have already wait dcf done in ATF, so don't need wait dcf irq > in kernel, besides, clear dcf irq in kernel will import competiton > between kernel and ATF, only handle dcf irq in ATF is a better way. > > Signed-off-by: Lin Huang > Signed-off-by: Enric Balletbo i Serra This does not apply

RE: [PATCH 1/6] dt-bindings: devfreq: rk3399_dmc: improve binding documentation.

f-by: Nick Milner <nick.mil...@collabora.com> >Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com> Acked-by: MyungJoo Ham <myungjoo@samsung.com> CC (The original author of this doc): Lin Huang <h...@rock-chips.com> Cheers, MyungJoo. >--

RE: [PATCH 1/6] dt-bindings: devfreq: rk3399_dmc: improve binding documentation.

: Enric Balletbo i Serra Acked-by: MyungJoo Ham CC (The original author of this doc): Lin Huang Cheers, MyungJoo. >--- > > .../bindings/devfreq/rk3399_dmc.txt | 207 +- > 1 file changed, 105 insertions(+), 102 deletions(-) > >diff --git a

  1   2   3   4   5   6   7   >