[PATCH 3/3] clockevents/exynos_mct: Implement ->set_state_oneshot_stopped()
set_state_oneshot_stopped() is called by the clkevt core, when the next
event is required at an expiry time of 'KTIME_MAX'. This normally
happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.
This patch makes the clockevent device to stop on such an event, to
avoid spurious interrupts, as explained by: commit 8fff52fd5093
("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
drivers/clocksource/exynos_mct.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index ff44082a0827..be09bc0b5e26 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -313,6 +313,7 @@ static struct clock_event_device mct_comp_device = {
.set_state_periodic = mct_set_state_periodic,
.set_state_shutdown = mct_set_state_shutdown,
.set_state_oneshot = mct_set_state_shutdown,
+ .set_state_oneshot_stopped = mct_set_state_shutdown,
.tick_resume= mct_set_state_shutdown,
};
@@ -452,6 +453,7 @@ static int exynos4_local_timer_setup(struct
mct_clock_event_device *mevt)
evt->set_state_periodic = set_state_periodic;
evt->set_state_shutdown = set_state_shutdown;
evt->set_state_oneshot = set_state_shutdown;
+ evt->set_state_oneshot_stopped = set_state_shutdown;
evt->tick_resume = set_state_shutdown;
evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
evt->rating = 450;
--
2.7.0.rc1.186.g94414c4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties
On 17-12-15, 19:04, Bartlomiej Zolnierkiewicz wrote:
> Commit 01fb4d3c39d3 ("PM / OPP: Parse 'opp--'
> bindings") broke support for parsing standard opp-microvolt and
> opp-microamp properties. Fix it by setting 'name' string to
> proper value for !prop cases.
>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> Fixes: 01fb4d3c39d3 ("PM / OPP: Parse 'opp-- 'bindings")
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> v2:
> - rework the changes as requested by Viresh
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties
On 16-12-15, 16:41, Bartlomiej Zolnierkiewicz wrote:
> Commit 01fb4d3c39d3 ("PM / OPP: Parse 'opp--'
> bindings") broke support for parsing standard opp-microvolt and
> opp-microamp properties. Fix it by setting 'name' string to
> proper value for !dev_opp->prop_name cases.
>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Lee Jones <lee.jo...@linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> Fixes: 01fb4d3c39d3 ("PM / OPP: Parse 'opp-- 'bindings")
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> This fixes Exynos4x12 cpufreq-dt support regression present in
> linux-pm/linux-next tree. Rafael, please apply. Thank you.
>
> drivers/base/power/opp/core.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> Index: b/drivers/base/power/opp/core.c
> ===
> --- a/drivers/base/power/opp/core.c 2015-12-16 16:10:13.509171420 +0100
> +++ b/drivers/base/power/opp/core.c 2015-12-16 16:21:18.385183902 +0100
> @@ -806,11 +806,11 @@ static int opp_parse_supplies(struct dev
> struct property *prop = NULL;
> char name[NAME_MAX];
>
> + sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
> +
> /* Search for "opp-microvolt-" */
> - if (dev_opp->prop_name) {
> - sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
> + if (dev_opp->prop_name)
> prop = of_find_property(opp->np, name, NULL);
> - }
>
> if (!prop) {
> /* Search for "opp-microvolt" */
> @@ -848,10 +848,10 @@ static int opp_parse_supplies(struct dev
>
> /* Search for "opp-microamp-" */
> prop = NULL;
> - if (dev_opp->prop_name) {
> - sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
> + sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
> +
> + if (dev_opp->prop_name)
> prop = of_find_property(opp->np, name, NULL);
> - }
>
> if (!prop) {
> /* Search for "opp-microamp" */
Sorry about this. And I am disliking the solution suggested by Stephen
more and more now. Please resend this patch with following changes
instead:
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 6c6856e426f0..a96df5cda303 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -816,7 +816,7 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,
struct device *dev,
if (!prop) {
/* Search for "opp-microvolt" */
- name[13] = '\0';
+ sprintf(name, "opp-microvolt");
prop = of_find_property(opp->np, name, NULL);
/* Missing property isn't a problem, but an invalid entry is */
@@ -857,7 +857,7 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,
struct device *dev,
if (!prop) {
/* Search for "opp-microamp" */
- name[12] = '\0';
+ sprintf(name, "opp-microamp");
prop = of_find_property(opp->np, name, NULL);
}
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 15-12-15, 18:33, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic cpufreq-dt driver support for > Exynos542x/5800 (using the new CPU clock type which allows it). > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. > > Depends on: > - next-20151211 branch of linux-next kernel tree > - "[PATCH] ARM: dts: Make CPU configuration more readable for > exynos542x/5800" patch (https://lkml.org/lkml/2015/12/11/107) > > Changes since v5: > - rebased over next-20151211 branch (something is broken in > newer branches, namely next-2015121[45]) > - rebased on top of "ARM: dts: Make CPU configuration more > readable for exynos542x/5800" patch > - renamed cpu0_opp_table to cluster_a15_opp_table and > cpu1_opp_table to cluster_a7_opp_table > - added Reviewed-by from Krzysztof Acked-by: Viresh Kumar <viresh.ku...@linaro.org> -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 00:25, Javier Martinez Canillas wrote: > The problem is that the big and LITTLE cores have different ordering per SoCs: > > - Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7) > - Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15) > > So the OPP tables are set in this DTSI file, to prevent the OPP tables > in the Exynos5422 to be inverted for the cluster 0 and 1. Oh dude, that's really *ugly*. :) Reusing files/definitions is fine to the point where things are readable. But you have screwed it up so very badly. Over that, why can't you keep cpu0-3 as A7 and 4-7 as a15 for all the cases? The only worrying thing for you should be that CPU0 within the kenrel should be controllable, right? i.e. you want a A15 to boot 5800 and A7 to boot 5422. If yes, than you could have kept the CPUs in 5422 as: 0-3: A7 4-7: A15 and in 5420 as: 4-7: A15 0-3: A7 Wouldnt' that work ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 13:00, Krzysztof Kozlowski wrote: > It wasn't working like this. The cpu0 got the index from booting cpu, so > on 5420 cpu0 was A15 and on 5422 it was A7. > > Maybe I am not aware of some changes recently in the kernel but how do > you want to assign the booting CPU proper number (not CPU0)? Okay, this is how it works and I don't think you need to change the order of CPUs based on machines. The boot CPU isn't controlled by the DT file but your bootloader, so it will be A15 on 5420 and A7 on 5422. Now if you keep the order in DT as: 0-3 A7 and 4-7 A15 irrespective of the SoCs, then this is how they will be assigned. Linux CPU numbers Actual CPU assigned to them 54205422 CPU0A15-0 (boot)A7-0 (boot) CPU1A7-0A7-1 CPU2A7-1A7-2 CPU3A7-2A7-3 CPU4A7-3A15-0 CPU5A15-1 A15-1 CPU6A15-2 A15-2 CPU7A15-3 A15-3 This happens because all non-boot CPUs will be added in the order they are present in DT. Now, there should be no *real* reason for you to want your CPUs to be always contiguous, isn't it? In the case of 5420, cpufreq will show related CPUs as: Policy0: CPU0,5-7, Policy1: CPU1-4 and in the case of 5422, cpufreq will show related CPUs as: Policy0: CPU0-3, Policy1: CPU4-7 And I think you should really fix this now.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote: > diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi > b/arch/arm/boot/dts/exynos5422-cpus.dtsi > index b7f60c8..9a5131d 100644 > --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi > +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi > @@ -20,8 +20,10 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x100>; > + clocks = < CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <_control0>; > + operating-points-v2 = <_opp_table>; > }; Why do you need to update this file? This file is included by exynos5422-odroidxu3-common.dtsi, which already inherits cpus nodes from exynos5800.dtsi (which inherits exynos5420.dtsi). i.e. operating-points-v2 should already be set. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800
On 11-12-15, 15:17, Krzysztof Kozlowski wrote: > Exynos5420 and Exynos5800 boards boot from big core (A15) but > Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this s/Exynos5420/Exynos5422 and then you can add Reviewed-by: Viresh Kumar <viresh.ku...@linaro.org> -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
> We had such configuration before (before df09df6f9ac3). I don't see any
> benefit in what you described. Where is the "thing" to be fixed? It is
> mixed up. The contiguous ordering is easier to read and more natural.
This is what you are doing today (keeping on one CPU per cluster to
simplify it):
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <18>;
cci-control-port = <_control1>;
};
cpu4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <10>;
cci-control-port = <_control0>;
};
Then you overwrite it with:
{
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <10>;
cci-control-port = <_control0>;
};
{
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <18>;
cci-control-port = <_control1>;
};
Don't you think this isn't the right way of solving problems?
The DT overwrite feature isn't there to do such kind of stuff, though
it doesn't stop you from doing that.
Either you should keep separate paths for both the SoCs, or can solve
it the way I suggested earlier.
This came up because in the current series you are doing this:
cpu0: cpu@0 {
compatible = "arm,cortex-a15";
operating-points-v2 = <_opp_table>;
};
cpu4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
operating-points-v2 = <_opp_table>;
};
Then you overwrite it with:
{
compatible = "arm,cortex-a7";
operating-points-v2 = <_opp_table>;
};
{
compatible = "arm,cortex-a15";
operating-points-v2 = <_opp_table>;
};
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 14:28, Krzysztof Kozlowski wrote: > Actually I think there is no nice way of making this as separate paths. > As Javier's mentioned, there aren't many differences. Currently the CPU > ordering is the only difference in DT. > > Making it as separate path would create hierarchy like: > - exynos5420-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > - exynos5422-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > which of course is okay... except we keep the definition of CPUs > completely outside of main Exynos5420 DTSI. Then we have to include both > DTSI for each new DTS. So what? There isn't anything wrong in this case and is just the right thing to do, IMHO. We have just kept the CPU devices separately, simple. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/8] ARM: dts: Exynos5420: add CPU OPP properties
On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote:
> + cpu1_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@13 {
This should be just opp@13, you don't need 00/01/02... anymore
now. Same for the other patch as well..
Fix that in other patches in this series and you also need to fix it
for arch/arm/boot/dts/exynos4212.dtsi based on what I see in
linux-next.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 08-12-15, 11:47, Viresh Kumar wrote: > On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > > > This patch series adds generic cpufreq-dt driver support for > > Exynos542x/5800 (using the new CPU clock type which allows it). > > > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. > > Excellent work Bartlomiej. Thanks a lot for adapting cpufreq-dt for > this. Really appreciate it :) You fix the oppXX@ problem and add my Acked-by: Viresh Kumar <viresh.ku...@linaro.org> for the entire series. Good work. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 07-12-15, 19:18, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic cpufreq-dt driver support for > Exynos542x/5800 (using the new CPU clock type which allows it). > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. Excellent work Bartlomiej. Thanks a lot for adapting cpufreq-dt for this. Really appreciate it :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 05-12-15, 08:49, Bartlomiej Zolnierkiewicz wrote: > Why I appreciate Ben's work this not exactly the same thing as > the above patchset lacks critical CLK_RECALC_NEW_RATES bugfix and > few other minor fixes. I am not saying that these are exactly same, code wise, but you are both targeting to solve the same problem. > > And the comments given there applies to you as well. > > Yes, sure. That's why I wrote that this is work-in-progress > and put the TODO in the cover letter. As I mentioned there, you need to migrate to cpufreq-dt instead of arm-big-little now. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 04-12-15, 18:30, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic arm_big_little_dt cpufreq driver > support for Exynos542x/5800 (using the new CPU clock type which > allows it). It also: > - enhances arm_big_little[_dt] driver with CPU cluster regulator > support > - adds CPU clock configuration data and CPU operating points > setup for Exynos542x/5800 > - adds CPU cluster regulator supplies for Exynos542x/5800 boards > > This patch series has been tested on Exynos5422 based ODROID-XU3 > Lite board. > > Please note that this is not a final version of the patchset. > I just wanted to push out current work-in-progress patches that > integrate changes from Anand, Ben and me. What's going on guys, Ben tried exactly same thing few days back: http://marc.info/?l=linux-kernel=144909193925508=2 And the comments given there applies to you as well. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422
On 03-12-15, 12:21, Ben Gamari wrote: > Do you mean something along these lines? [1] Yeah. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422
On 03-12-15, 11:05, Sudeep Holla wrote: > The main difference is that we get the OPPs from the firmware rather > than DT. We may just need to abstract that part and we should be able to > use it. I will have a look at it and get back to you will more details. > It has been a while since I looked at cpufreq-dt. I forgot that :( .. but we can then create OPPs at runtime based on what's available from firmware. And we also have an API now to set which CPUs share OPPs... so that might be used as well.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422
On 03-12-15, 11:26, Ben Gamari wrote: > Viresh Kumar <viresh.ku...@linaro.org> writes: > > But, before I start reviewing this series, I have few comments. > > - We weren't able to use cpufreq-dt driver for big LITTLE platforms > > earlier, as it never had multi cluster support and we wanted > > clock-sharing information via DT. > > Fair enough. > > > - That is all fixed now. > > I did not see any mention of this in the cpufreq-dt driver binding > documentation, otherwise I would have tried going this route. > > Do you have any references? I'd be happy to examine what would be > necessary to go this route although, being an independent contributor, > it may take time. You wouldn't find in cpufreq-dt documentation as its not specific to that. I have seen you DT patches now, and you have created the OPP tables mostly correctly. Just create the cpufreq-platform device for cpufreq-dt instead of arm-big-little one. And it should just work. > > - I want Samsung's big LITTLE platforms to use cpufreq-dt and drop > > arm_big_little driver completely. > > That sounds like a great direction going forward. However, I would still > kindly request that you consider this series. > > The existence of future plans of course does not change the fact that > users have real hardware today; hardware that they have spent money on > and would like to use. Cpufreq support has already been deferred once > for similar reasons of interface churn which essentially forestalled > working functionality from entering the kernel by eight months; I'd > really like to avoid having this happen again. I am not talking about any future plans here that need some work to be done. Its all working today, you just need to use a different driver. > Sounds reasonable to me. However, I'd just like to reiterate that this > line of work can be pursued independently from the upstreaming of this > series. I think this is the right time to upstream the right solution. Just try it once, if you face lots of difficulties or issues, then we can ofcourse see.. NOTE: Check how OPP nodes are required to be created now in linux-next. They should be named like opp@. Something I noticed in your DTs. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422
Hi Ben, On 02-12-15, 22:19, Ben Gamari wrote: > > This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422 > SOCs. In particular, it adds support for operating-points-v2 bindings to the > arm-big-little cpufreq driver and updates the above-mentioned SOCs' > devicetrees > to take advantage of this support. There are also a couple of patches > improving > the clarify of the arm-big-little implementation. It is built on a set posted > by Bartlomiej Zolnierkiewicz in April 2015. > > The most signficant change from the original series is porting to the > operating-points-v2 devicetree bindings. The series has been tested by me on > and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit. Thanks for working with opp-v2 bindings, really appreciate it. But, before I start reviewing this series, I have few comments. - We weren't able to use cpufreq-dt driver for big LITTLE platforms earlier, as it never had multi cluster support and we wanted clock-sharing information via DT. - That is all fixed now. - I want Samsung's big LITTLE platforms to use cpufreq-dt and drop arm_big_little driver completely. - The only case for which it (arm_big_little) driver might be useful is the IKS solution. Which I don't believe you are going to use in future :) My plan for the arm-big-little driver: - Migrate all platforms to use cpufreq-dt instead for non-IKS solution - Make arm-big-little driver arm-big-little-iks only driver. @Sudeep: What would it take you to use cpufreq-dt for ARM's platforms ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 294cfe40388d..40beede46e55 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -64,73 +64,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp01 {
+ opp@3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp02 {
+ opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <925000>;
clock-latency-ns = <20>;
};
- opp03 {
+ opp@5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <95>;
clock-latency-ns = <20>;
};
- opp04 {
+ opp@6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <975000>;
clock-latency-ns = <20>;
};
- opp05 {
+ opp@7 {
opp-hz = /bits/ 64 <7>;
opp-microvolt = <987500>;
clock-latency-ns = <20>;
};
- opp06 {
+ opp@8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <100>;
clock-latency-ns = <20>;
opp-suspend;
};
- opp07 {
+ opp@9 {
opp-hz = /bits/ 64 <9>;
opp-microvolt = <1037500>;
clock-latency-ns = <20>;
};
- opp08 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1087500>;
clock-latency-ns = <20>;
};
- opp09 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <1137500>;
clock-latency-ns = <20>;
};
- opp10 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1187500>;
clock-latency-ns = <20>;
};
- opp11 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <125>;
clock-latency-ns = <20>;
};
- opp12 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1287500>;
clock-latency-ns = <20>;
};
- opp13 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <135>;
clock-latency-ns = <20>;
--
2.6.2.198.g614a2ac
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
On 05-11-15, 10:51, Krzysztof Kozlowski wrote: > I see this patch does not depend on the rest of patchset so I presume > this can co through samsung-soc? Yeah, I wouldn't mind that. But I would wait for a confirmation from Rafael for the bindings first, for an unlikely case where he doesn't like the fourth patch ;) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 294cfe40388d..40beede46e55 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -64,73 +64,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp01 {
+ opp@3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp02 {
+ opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <925000>;
clock-latency-ns = <20>;
};
- opp03 {
+ opp@5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <95>;
clock-latency-ns = <20>;
};
- opp04 {
+ opp@6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <975000>;
clock-latency-ns = <20>;
};
- opp05 {
+ opp@7 {
opp-hz = /bits/ 64 <7>;
opp-microvolt = <987500>;
clock-latency-ns = <20>;
};
- opp06 {
+ opp@8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <100>;
clock-latency-ns = <20>;
opp-suspend;
};
- opp07 {
+ opp@9 {
opp-hz = /bits/ 64 <9>;
opp-microvolt = <1037500>;
clock-latency-ns = <20>;
};
- opp08 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1087500>;
clock-latency-ns = <20>;
};
- opp09 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <1137500>;
clock-latency-ns = <20>;
};
- opp10 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1187500>;
clock-latency-ns = <20>;
};
- opp11 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <125>;
clock-latency-ns = <20>;
};
- opp12 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1287500>;
clock-latency-ns = <20>;
};
- opp13 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <135>;
clock-latency-ns = <20>;
--
2.6.2.198.g614a2ac
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] cpufreq-dt: add suspend frequency support
On 14-09-15, 16:08, Krzysztof Kozlowski wrote: > If you want, the fourth patch can go now through your tree - the late > SoC changes were pulled by Linus. No difference... I can grab it as I > had other DT related fix in queue. > > The only important thing is to get entire patchset to 4.3 because it is > a fix for regression introduced in cpufreq for exynos. Do you plan to > send your part in current 4.3 cycle? The first 3 patches are already part for 4.3-rc1 and so you can keep the DT update in your tree now. :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs
On 08-09-15, 19:02, Bartlomiej Zolnierkiewicz wrote:
> CONFIG_PM ifdefs are superfluous and can be removed.
>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> drivers/cpufreq/s5pv210-cpufreq.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index 9e231f5..ef5282b 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -576,10 +576,8 @@ static struct cpufreq_driver s5pv210_driver = {
> .get= cpufreq_generic_get,
> .init = s5pv210_cpu_init,
> .name = "s5pv210",
> -#ifdef CONFIG_PM
> .suspend= cpufreq_generic_suspend,
> .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ
> again */
> -#endif
> };
>
> static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] ARM: dts: add suspend opp to exynos4412
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Mark 800MHz OPP as a suspend opp for Exynos4412 based
> boards so effectively cpufreq-dt driver behavior w.r.t.
> suspend frequency matches what the old exynos-cpufreq
> driver has been doing.
>
> This patch fixes suspend/resume support on Exynos4412 based
> Trats2 board and reboot hang on Exynos4412 based Odroid U3
> board.
>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Marek Szyprowski <m.szyprow...@samsung.com>
> Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index ca0e3c1..294cfe4 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -98,6 +98,7 @@
> opp-hz = /bits/ 64 <8>;
> opp-microvolt = <100>;
> clock-latency-ns = <20>;
> + opp-suspend;
> };
> opp07 {
> opp-hz = /bits/ 64 <9>;
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] cpufreq-dt: add suspend frequency support
On 07-09-15, 17:41, Bartlomiej Zolnierkiewicz wrote: > +#ifdef CONFIG_PM > + .suspend = cpufreq_generic_suspend, > +#endif I don't think there is any need of the #ifdef here. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 07-09-15, 17:41, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds suspend frequency support (using opp-v2 > bindings and suspend-opp functionality) to cpufreq-dt driver and > then adds suspend opp for Exynos4412 based boards. > > This patch series fixes suspend/resume support on Exynos4412 > based Trats2 board and reboot hang on Exynos4412 based Odroid > U3 board. > > Changes since v3: > - fixed dev_pm_opp_get_suspend_opp() locking > - shortened variable name in dev_pm_opp_get_suspend_opp() > - adjusted cpufreq_generic_suspend() to work with cpufreq-dt > - removed no longer needed cpufreq_dt_suspend() > - added Acked-by tag from Viresh to patch #4 Just a minor comment on 3/4 and after fixing that: Acked-by: Viresh Kumar <viresh.ku...@linaro.org> -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08-09-15, 13:48, Krzysztof Kozlowski wrote: > Somehow my mind stuck on solving Exynos4x12 cpufreq issues. > > Right, it should go through Rafael's, probably except DTS patch (4/4) > because it depends on previous DTS changes. These changes are still in > arm-soc, not in Linus' tree [0]. That's bad :( Anyway, 4/4 is kind of independent to this series, in the sense that it wouldn't harm even if it gets applied separately. So, go ahead and apply 4/4 to Samsung's tree and rest of this can be picked by Rafael. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] cpufreq-dt: add suspend frequency support
On 08-09-15, 12:56, Krzysztof Kozlowski wrote: > There were no comments from your side for this patchset nor for previous > Marek's fix. After mentioned change and Bart's re-spin, do you plan to > grab this patchset and send it for current v4.3 cycle? Why do you think it should go via Kukjin's tree and not Rafael's? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] PM / OPP: add dev_pm_opp_get_suspend_opp() helper
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Marek Szyprowski <m.szyprow...@samsung.com>
> Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> drivers/base/power/opp.c | 28
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index eb25449..eaafca7 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -341,6 +341,34 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct
> device *dev)
> EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_clock_latency);
>
> /**
> + * dev_pm_opp_get_suspend_opp() - Get suspend opp
> + * @dev: device for which we do this operation
> + *
> + * Return: This function returns pointer to the suspend opp if it is
> + * defined, otherwise it returns NULL.
> + *
> + * Locking: This function takes rcu_read_lock().
> + */
> +struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev)
> +{
> + struct device_opp *dev_opp;
> + struct dev_pm_opp *suspend_opp;
> +
> + rcu_read_lock();
This is wrong. Please have a look at other exported APIs that return
an OPP. RCU protected structures must be accessed from within RCU
locks _ONLY_. But your function returns the pointer after dropping
the locks. Which essentially means that the OPP can be freed by core,
by the time you start using it. :)
So, in such cases, its upto the caller to ensure that locks are taken
properly.
You can look at dev_pm_opp_find_freq_exact() as an example.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] cpufreq-dt: add suspend frequency support
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional). Also implement
> custom suspend method (needed to not error out on platforms
> which don't require suspend frequency).
>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Thomas Abraham <thomas...@samsung.com>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Marek Szyprowski <m.szyprow...@samsung.com>
> Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
> ---
> drivers/cpufreq/cpufreq-dt.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> +#ifdef CONFIG_PM
> +static int cpufreq_dt_suspend(struct cpufreq_policy *policy)
> +{
> + int ret;
> +
> + if (!policy->suspend_freq) {
> + pr_debug("%s: suspend_freq not defined\n", __func__);
> + return 0;
> + }
> +
> + pr_debug("%s: Setting suspend-freq: %u\n", __func__,
> + policy->suspend_freq);
> +
> + ret = __cpufreq_driver_target(policy, policy->suspend_freq,
> + CPUFREQ_RELATION_H);
> + if (ret)
> + pr_err("%s: unable to set suspend-freq: %u. err: %d\n",
> + __func__, policy->suspend_freq, ret);
> +
> + return ret;
> +}
> +#else
> +#define cpufreq_dt_suspend NULL
> +#endif
No, there is no point replicating the exactly same routine again.
Rather modify cpufreq_generic_suspend() to not print error and instead
do pr_debug(), on !policy->suspend_freq.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/6] PM / OPP: Prefix exported opp routines with dev_pm_opp_
That's the naming convention followed in most of opp core, but few
routines didn't follow this, fix them.
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
arch/arm/mach-imx/mach-imx6q.c | 2 +-
drivers/base/power/opp.c | 41 ++--
drivers/cpufreq/arm_big_little.h | 2 +-
drivers/cpufreq/arm_big_little_dt.c | 4 ++--
drivers/cpufreq/cpufreq-dt.c | 10 -
drivers/cpufreq/exynos5440-cpufreq.c | 6 +++---
drivers/cpufreq/imx6q-cpufreq.c | 6 +++---
drivers/cpufreq/mt8173-cpufreq.c | 6 +++---
include/linux/pm_opp.h | 24 ++---
9 files changed, 51 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 3286eec91d92..3878494bd118 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -350,7 +350,7 @@ static void __init imx6q_opp_init(void)
return;
}
- if (of_add_opp_table(cpu_dev)) {
+ if (dev_pm_opp_of_add_table(cpu_dev)) {
pr_warn("failed to init OPP table\n");
goto put_node;
}
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 1515c05bc579..f42ffa517156 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -800,8 +800,8 @@ static int _opp_add(struct device *dev, struct dev_pm_opp
*new_opp,
* The opp is made available by default and it can be controlled using
* dev_pm_opp_enable/disable functions and may be removed by dev_pm_opp_remove.
*
- * NOTE: "dynamic" parameter impacts OPPs added by the of_add_opp_table and
- * freed by of_remove_opp_table.
+ * NOTE: "dynamic" parameter impacts OPPs added by the dev_pm_opp_of_add_table
+ * and freed by dev_pm_opp_of_remove_table.
*
* Locking: The internal device_opp and opp structures are RCU protected.
* Hence this function internally uses RCU updater strategy with mutex locks
@@ -1185,7 +1185,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_notifier);
#ifdef CONFIG_OF
/**
- * of_remove_opp_table() - Free OPP table entries created from static DT
entries
+ * dev_pm_opp_of_remove_table() - Free OPP table entries created from static DT
+ * entries
* @dev: device pointer used to lookup device OPPs.
*
* Free OPPs created using static entries present in DT.
@@ -1196,7 +1197,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_notifier);
* that this function is *NOT* called under RCU protection or in contexts where
* mutex cannot be locked.
*/
-void of_remove_opp_table(struct device *dev)
+void dev_pm_opp_of_remove_table(struct device *dev)
{
struct device_opp *dev_opp;
struct dev_pm_opp *opp, *tmp;
@@ -1231,9 +1232,9 @@ void of_remove_opp_table(struct device *dev)
unlock:
mutex_unlock(_opp_list_lock);
}
-EXPORT_SYMBOL_GPL(of_remove_opp_table);
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
-void of_cpumask_remove_opp_table(cpumask_var_t cpumask)
+void dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
{
struct device *cpu_dev;
int cpu;
@@ -1248,10 +1249,10 @@ void of_cpumask_remove_opp_table(cpumask_var_t cpumask)
continue;
}
- of_remove_opp_table(cpu_dev);
+ dev_pm_opp_of_remove_table(cpu_dev);
}
}
-EXPORT_SYMBOL_GPL(of_cpumask_remove_opp_table);
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_remove_table);
/* Returns opp descriptor node for a device, caller must do of_node_put() */
static struct device_node *_of_get_opp_desc_node(struct device *dev)
@@ -1309,7 +1310,7 @@ static int _of_add_opp_table_v2(struct device *dev,
struct device_node *opp_np)
return 0;
free_table:
- of_remove_opp_table(dev);
+ dev_pm_opp_of_remove_table(dev);
return ret;
}
@@ -1352,7 +1353,7 @@ static int _of_add_opp_table_v1(struct device *dev)
}
/**
- * of_add_opp_table() - Initialize opp table from device tree
+ * dev_pm_opp_of_add_table() - Initialize opp table from device tree
* @dev: device pointer used to lookup device OPPs.
*
* Register the initial OPP table with the OPP library for given device.
@@ -1374,7 +1375,7 @@ static int _of_add_opp_table_v1(struct device *dev)
* -ENODATAwhen empty 'operating-points' property is found
* -EINVAL when invalid entries are found in opp-v2 table
*/
-int of_add_opp_table(struct device *dev)
+int dev_pm_opp_of_add_table(struct device *dev)
{
struct device_node *opp_np;
int ret;
@@ -1397,9 +1398,9 @@ int of_add_opp_table(struct device *dev)
return ret;
}
-EXPORT_SYMBOL_GPL(of_add_opp_table);
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_add_table);
-int of_cpumask_add_opp_table(cpumask_var_t cpumask)
+int dev_pm_opp_of_cpumask_add_table(cpumask_var_t cpumask)
{
struct device *cpu_
[PATCH V3 2/6] PM / OPP: Rename opp init/free table routines
free-table routines are opposite of init-table ones, and must be named
to make that clear. Opposite of 'init' is 'exit', but those doesn't suit
really well.
Replace 'init' with 'add' and 'free' with 'remove'.
Reported-by: Pavel Machek <pa...@ucw.cz>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
arch/arm/mach-imx/mach-imx6q.c | 2 +-
drivers/base/power/opp.c | 41 ++--
drivers/cpufreq/arm_big_little.h | 2 +-
drivers/cpufreq/arm_big_little_dt.c | 4 ++--
drivers/cpufreq/cpufreq-dt.c | 6 +++---
drivers/cpufreq/exynos5440-cpufreq.c | 6 +++---
drivers/cpufreq/imx6q-cpufreq.c | 6 +++---
drivers/cpufreq/mt8173-cpufreq.c | 6 +++---
include/linux/pm_opp.h | 16 +++---
9 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 9602cc12d2f1..3286eec91d92 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -350,7 +350,7 @@ static void __init imx6q_opp_init(void)
return;
}
- if (of_init_opp_table(cpu_dev)) {
+ if (of_add_opp_table(cpu_dev)) {
pr_warn("failed to init OPP table\n");
goto put_node;
}
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 4741fdc13e83..1515c05bc579 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -800,8 +800,8 @@ static int _opp_add(struct device *dev, struct dev_pm_opp
*new_opp,
* The opp is made available by default and it can be controlled using
* dev_pm_opp_enable/disable functions and may be removed by dev_pm_opp_remove.
*
- * NOTE: "dynamic" parameter impacts OPPs added by the of_init_opp_table and
- * freed by of_free_opp_table.
+ * NOTE: "dynamic" parameter impacts OPPs added by the of_add_opp_table and
+ * freed by of_remove_opp_table.
*
* Locking: The internal device_opp and opp structures are RCU protected.
* Hence this function internally uses RCU updater strategy with mutex locks
@@ -1185,7 +1185,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_notifier);
#ifdef CONFIG_OF
/**
- * of_free_opp_table() - Free OPP table entries created from static DT entries
+ * of_remove_opp_table() - Free OPP table entries created from static DT
entries
* @dev: device pointer used to lookup device OPPs.
*
* Free OPPs created using static entries present in DT.
@@ -1196,7 +1196,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_notifier);
* that this function is *NOT* called under RCU protection or in contexts where
* mutex cannot be locked.
*/
-void of_free_opp_table(struct device *dev)
+void of_remove_opp_table(struct device *dev)
{
struct device_opp *dev_opp;
struct dev_pm_opp *opp, *tmp;
@@ -1231,9 +1231,9 @@ void of_free_opp_table(struct device *dev)
unlock:
mutex_unlock(_opp_list_lock);
}
-EXPORT_SYMBOL_GPL(of_free_opp_table);
+EXPORT_SYMBOL_GPL(of_remove_opp_table);
-void of_cpumask_free_opp_table(cpumask_var_t cpumask)
+void of_cpumask_remove_opp_table(cpumask_var_t cpumask)
{
struct device *cpu_dev;
int cpu;
@@ -1248,10 +1248,10 @@ void of_cpumask_free_opp_table(cpumask_var_t cpumask)
continue;
}
- of_free_opp_table(cpu_dev);
+ of_remove_opp_table(cpu_dev);
}
}
-EXPORT_SYMBOL_GPL(of_cpumask_free_opp_table);
+EXPORT_SYMBOL_GPL(of_cpumask_remove_opp_table);
/* Returns opp descriptor node for a device, caller must do of_node_put() */
static struct device_node *_of_get_opp_desc_node(struct device *dev)
@@ -1267,8 +1267,7 @@ static struct device_node *_of_get_opp_desc_node(struct
device *dev)
}
/* Initializes OPP tables based on new bindings */
-static int _of_init_opp_table_v2(struct device *dev,
-struct device_node *opp_np)
+static int _of_add_opp_table_v2(struct device *dev, struct device_node *opp_np)
{
struct device_node *np;
struct device_opp *dev_opp;
@@ -1310,13 +1309,13 @@ static int _of_init_opp_table_v2(struct device *dev,
return 0;
free_table:
- of_free_opp_table(dev);
+ of_remove_opp_table(dev);
return ret;
}
/* Initializes OPP tables based on old-deprecated bindings */
-static int _of_init_opp_table_v1(struct device *dev)
+static int _of_add_opp_table_v1(struct device *dev)
{
const struct property *prop;
const __be32 *val;
@@ -1353,7 +1352,7 @@ static int _of_init_opp_table_v1(struct device *dev)
}
/**
- * of_init_opp_table() - Initialize opp table from device tree
+ * of_add_opp_table() - Initialize opp table from device tree
* @dev: device pointer used to lookup device OPPs.
*
* Register the initial OPP table with the OPP library for given device.
@@ -1375,7 +1374,7 @@ sta
Re: [PATCH] cpufreq-dt: add suspend frequency support
On 02-09-15, 18:42, Bartlomiej Zolnierkiewicz wrote: > Add suspend frequency support and set it to the boot frequency, > this matches what the old exynos-cpufreq driver has been doing. > > This patch fixes suspend/resume support on Exynos4412 based > Trats2 board and reboot hang on Exynos4412 based Odroid U3 > board. > > Cc: Viresh Kumar <viresh.ku...@linaro.org> > Cc: Thomas Abraham <thomas...@samsung.com> > Cc: Javier Martinez Canillas <jav...@osg.samsung.com> > Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com> > Cc: Marek Szyprowski <m.szyprow...@samsung.com> > Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> > --- > This patch supersedes "[PATCH] ARM: dts: exynos4412-odroid-*: add > workaround for CPUfreq/reboot issue" one from yesterday. > > drivers/cpufreq/cpufreq-dt.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c > index c3583cd..c9138c7 100644 > --- a/drivers/cpufreq/cpufreq-dt.c > +++ b/drivers/cpufreq/cpufreq-dt.c > @@ -329,6 +329,10 @@ static int cpufreq_init(struct cpufreq_policy *policy) > policy->driver_data = priv; > > policy->clk = cpu_clk; > + > + /* capture boot frequency */ > + policy->suspend_freq = clk_get_rate(cpu_clk) / 1000;; We should be using opp-v2's suspend-opp thing for this now.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq-dt: add suspend frequency support
On 02-09-15, 11:03, Stephen Boyd wrote: > On 09/02/2015 09:47 AM, Bartlomiej Zolnierkiewicz wrote: > > Add suspend frequency support and set it to the boot frequency, > > this matches what the old exynos-cpufreq driver has been doing. > > > > This patch fixes suspend/resume support on Exynos4412 based > > Trats2 board and reboot hang on Exynos4412 based Odroid U3 > > board. > > > > Cc: Viresh Kumar <viresh.ku...@linaro.org> > > Cc: Thomas Abraham <thomas...@samsung.com> > > Cc: Javier Martinez Canillas <jav...@osg.samsung.com> > > Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com> > > Cc: Marek Szyprowski <m.szyprow...@samsung.com> > > Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de> > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> > > --- > > This patch supersedes "[PATCH] ARM: dts: exynos4412-odroid-*: add > > workaround for CPUfreq/reboot issue" one from yesterday. > > What do we do about cpufreq-dt users that don't want to change frequency > during suspend? Again, this should be done via opp-v2 suspend-opp feature instead. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] cpufreq: make scaling_boost_freqs sysfs attr available when boost is enabled
On 07-08-15, 12:34, Bartlomiej Zolnierkiewicz wrote: I would suggest you sending such patches as reply to the earlier threads only, instead of a new chain. This will save your time. Please explain it more. This patch needs to be first for cpufreq-dt switch to be complete. scaling_boost_freqs is available currently for exynos-cpufreq users when boost is enabled and ideally we would like it to be available immediately after the switch to cpufreq-dt. I wasn't talking about the ordering of the patches here, but when to send patches. So, you now sent these patches again, but what you could have done is: only send the first patch in reply to the earlier thread. And ask if it looks fine. If yes, resend the whole series properly or keep fixing there only.. That makes things really fast. You don't have to resend the series and people wouldn't stay away from it. I stayed away from this series to find enough available time to see your 6 patches. Had it been just a reply, I would have replied immediately like now. Look at how updated versions in the same mail chain in case of OPP series.. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] cpufreq: make scaling_boost_freqs sysfs attr available when boost is enabled
On 07-08-15, 13:12, Bartlomiej Zolnierkiewicz wrote:
From 993ebb6fc632ec7b61654c9610c90ff4dca4be34 Mon Sep 17 00:00:00 2001
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Date: Fri, 7 Aug 2015 13:07:51 +0200
Subject: [PATCH] cpufreq-dt: make scaling_boost_freqs sysfs attr available
when boost is enabled
Make scaling_boost_freqs sysfs attribute is available when
cpufreq-dt driver is used and boost support is enabled.
Cc: Thomas Abraham thomas...@samsung.com
Cc: Javier Martinez Canillas jav...@osg.samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Suggested-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/cpufreq/cpufreq-dt.c | 11 ++-
include/linux/cpufreq.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b9259ab..c6a3b98 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -36,6 +36,12 @@ struct private_data {
unsigned int voltage_tolerance; /* in percentage */
};
+static struct freq_attr *cpufreq_dt_attr[] = {
+ cpufreq_freq_attr_scaling_available_freqs,
+ NULL, /* Extra space for boost-attr if required */
+ NULL,
+};
+
static int set_target(struct cpufreq_policy *policy, unsigned int index)
{
struct dev_pm_opp *opp;
@@ -182,6 +188,8 @@ try_again:
return ret;
}
+static struct cpufreq_driver dt_cpufreq_driver;
+
static int cpufreq_init(struct cpufreq_policy *policy)
{
struct cpufreq_frequency_table *freq_table;
@@ -336,6 +344,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
ret = cpufreq_enable_boost_support();
if (ret)
goto out_free_cpufreq_table;
+ cpufreq_dt_attr[1] = cpufreq_freq_attr_scaling_boost_freqs;
}
policy-cpuinfo.transition_latency = transition_latency;
@@ -411,7 +420,7 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.exit = cpufreq_exit,
.ready = cpufreq_ready,
.name = cpufreq-dt,
- .attr = cpufreq_generic_attr,
+ .attr = cpufreq_dt_attr,
};
static int dt_cpufreq_probe(struct platform_device *pdev)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 95f0186..657542d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -609,6 +609,7 @@ struct cpufreq_frequency_table
*cpufreq_frequency_get_table(unsigned int cpu);
/* the following are really really optional */
extern struct freq_attr cpufreq_freq_attr_scaling_available_freqs;
+extern struct freq_attr cpufreq_freq_attr_scaling_boost_freqs;
extern struct freq_attr *cpufreq_generic_attr[];
int cpufreq_table_validate_and_show(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *table);
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:31, Bartlomiej Zolnierkiewicz wrote: Users don't need to enable the config option to get boost functionality working. It is only needed to get scaling_boost_freqs sysfs attribute visible (which lists available boost freqs) when using cpufreq-dt driver. Also the config option in question is not user visible. By users I meant the people who will prepare the build images for the release. They can just enable the config option :) The worst thing that happens if these 2 PM patches don't make it in time is that there will be no scaling_boost_freqs available when using cpufreq-dt driver. Which is not very important from Exynos4x12 POV as it only supports single boost freq currently. Right. So, now that your patch is Acked, send 1/6 and 6/6 separately to pm-list and Rafael can get them merged himself.. I hope, your 6/6 patch will change a bit now ? -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:47, Bartlomiej Zolnierkiewicz wrote: Hmm, wait. Patch 6/6 depends on earlier changes. I cannot remove the config option in question now as it is currently used by exynos-cpufreq specific boost support. Patch 1/6 can be applied now but 6/6 needs to wait for patches 2-5 to be applied first. Actually 6/6 is trivial and can be applied later in v4.3 cycle or even in v4.4 one. Ack. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq-dt: make scaling_boost_freqs sysfs attr available when boost is enabled
On 07-08-15, 13:56, Bartlomiej Zolnierkiewicz wrote: Make scaling_boost_freqs sysfs attribute is available when cpufreq-dt driver is used and boost support is enabled. Cc: Thomas Abraham thomas...@samsung.com Cc: Javier Martinez Canillas jav...@osg.samsung.com Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Suggested-by: Viresh Kumar viresh.ku...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- v2: Removed leftover prototype. drivers/cpufreq/cpufreq-dt.c | 9 - include/linux/cpufreq.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] cpufreq: make scaling_boost_freqs sysfs attr available when boost is enabled
On 08-08-15, 00:21, Rafael J. Wysocki wrote: Acked-by: Viresh Kumar viresh.ku...@linaro.org And what exactly am I supposed to do with this? Have a robot that will pick up all patches ACKed by you magically or what? :) That's why I have asked Bartlomiej specifically to send it separately to the pm list as a cpufreq patch. I wasn't expecting you to apply right from here. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 08-08-15, 00:24, Rafael J. Wysocki wrote: OK, so please let me know which patches you want me to pick up. Ideally, I'd prefer them to be resent in a separate series with ACKs and all with a cover letter clearly stating whose tree they are being targeted at. He already sent it separately, let me send a confirmatory mail in reply to that. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cpufreq-dt: make scaling_boost_freqs sysfs attr available when boost is enabled
On 07-08-15, 13:59, Bartlomiej Zolnierkiewicz wrote: Make scaling_boost_freqs sysfs attribute is available when cpufreq-dt driver is used and boost support is enabled. Cc: Thomas Abraham thomas...@samsung.com Cc: Javier Martinez Canillas jav...@osg.samsung.com Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Suggested-by: Viresh Kumar viresh.ku...@linaro.org Acked-by: Viresh Kumar viresh.ku...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- v2: Removed leftover prototype. v3: added missing Acked-by Sorry for two resends, this is not my day.. Rafael, please apply for v4.3. Yeah, please apply only this patch from the series. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
Cc'ing Rafael again. Guys please don't miss him for any PM related stuff or use get_maintainers .. Cc'ing Arnd/Olof as well to discuss the merge stuff.. On 07-08-15, 08:53, Kukjin Kim wrote: Depends on: - next-20150806 branch of linux-next kernel tree - [PATCH V3 00/16] OPP: Add code to support operating-points-v2 bindings (http://www.spinics.net/lists/arm-kernel/msg435408.html) BTW, hmm...how can we see this series in v4.3?...to be honest, I don't think it can be done in v4.3 because of dependencies with PM / OPP series That is merged by Rafael Yesterday. That is manageable and previous exynos CPU OPP series in each cross trees...maybe that's why you created based on linux-next...any idea? So there is no build dependency with OPP patches I hope, as its all about using the bindings defined by them. And so you don't need to depend on that. You might have to rebase on the ARM tree to manage your conflicts. In this case you can rebase directly on ARM SoC branch which has your patches (rebase directly over the last patch instead of the whole branch) and make sure Olof knows about this and he doesn't update (i.e. rebase) his branch, which he might not anyway. The whole idea is to keep a single sha-id for a commit. So you can rebase over the published material present in ARM-SoC .. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/6] cpufreq: remove no longer needed CPU_FREQ_BOOST_SW config option
On 06-08-15, 15:41, Bartlomiej Zolnierkiewicz wrote: Remove no longer needed CPU_FREQ_BOOST_SW config option. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Thomas Abraham thomas...@samsung.com Cc: Javier Martinez Canillas jav...@osg.samsung.com Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/cpufreq/Kconfig | 4 drivers/cpufreq/freq_table.c | 3 --- 2 files changed, 7 deletions(-) This must be applied only after fixing 1/6. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
Fixed Olof's email id.. On 07-08-15, 09:20, Viresh Kumar wrote: Cc'ing Rafael again. Guys please don't miss him for any PM related stuff or use get_maintainers .. Cc'ing Arnd/Olof as well to discuss the merge stuff.. On 07-08-15, 08:53, Kukjin Kim wrote: Depends on: - next-20150806 branch of linux-next kernel tree - [PATCH V3 00/16] OPP: Add code to support operating-points-v2 bindings (http://www.spinics.net/lists/arm-kernel/msg435408.html) BTW, hmm...how can we see this series in v4.3?...to be honest, I don't think it can be done in v4.3 because of dependencies with PM / OPP series That is merged by Rafael Yesterday. That is manageable and previous exynos CPU OPP series in each cross trees...maybe that's why you created based on linux-next...any idea? So there is no build dependency with OPP patches I hope, as its all about using the bindings defined by them. And so you don't need to depend on that. You might have to rebase on the ARM tree to manage your conflicts. In this case you can rebase directly on ARM SoC branch which has your patches (rebase directly over the last patch instead of the whole branch) and make sure Olof knows about this and he doesn't update (i.e. rebase) his branch, which he might not anyway. The whole idea is to keep a single sha-id for a commit. So you can rebase over the published material present in ARM-SoC .. -- viresh -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:52, Krzysztof Kozlowski wrote: Thanks for explanation. As fair as I understand, Bartlomiej wanted to merge this in a way which would avoid loosing the boost mode. Kukjin prepared topic branches for previous cpu-freq/clk stuff so maybe everything could go through PM? We aren't loosing anything at all. There can be two cases here: 1. Patch 1/6 and 6/6 make it to 4.3 (with suggested changes) via PM tree: - All will work fine in this case, no issues at all.. 2. They don't make it: - Even in this case, nothing will break. Users can just enable a config option and that's all.. So, no need to divert things into another tree this late. Over that, Rafael will not be around for 2 weeks now (Plumbers and other stuff) .. So, just target the cpufreq core changes via PM tree.. rest is just fine. I hope that makes sense :) -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] cpufreq: make scaling_boost_freqs sysfs attr available when boost is enabled
Hi,
I would suggest you sending such patches as reply to the earlier
threads only, instead of a new chain. This will save your time.
For example, you will need to resend other patches unnecessarily if I
NAK this patch :)
On 06-08-15, 15:41, Bartlomiej Zolnierkiewicz wrote:
Add cpufreq_boost_enabled_generic_attr table and use it in
cpufreq-dt driver instead of cpufreq_generic_attr one when
boost support is enabled. As a result scaling_boost_freqs
sysfs attribute is available when cpufreq-dt driver is
used and boost support is enabled.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Thomas Abraham thomas...@samsung.com
Cc: Javier Martinez Canillas jav...@osg.samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/cpufreq/cpufreq-dt.c | 3 +++
drivers/cpufreq/freq_table.c | 7 +++
include/linux/cpufreq.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b9259ab..7b091c0 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -182,6 +182,8 @@ try_again:
return ret;
}
+static struct cpufreq_driver dt_cpufreq_driver;
+
static int cpufreq_init(struct cpufreq_policy *policy)
{
struct cpufreq_frequency_table *freq_table;
@@ -336,6 +338,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
ret = cpufreq_enable_boost_support();
if (ret)
goto out_free_cpufreq_table;
+ dt_cpufreq_driver.attr = cpufreq_boost_enabled_generic_attr;
}
policy-cpuinfo.transition_latency = transition_latency;
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index a8f1daf..5a00a09 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -300,6 +300,13 @@ struct freq_attr *cpufreq_generic_attr[] = {
};
EXPORT_SYMBOL_GPL(cpufreq_generic_attr);
+struct freq_attr *cpufreq_boost_enabled_generic_attr[] = {
+ cpufreq_freq_attr_scaling_available_freqs,
+ cpufreq_freq_attr_scaling_boost_freqs,
+ NULL,
+};
+EXPORT_SYMBOL_GPL(cpufreq_boost_enabled_generic_attr);
This isn't scalable. We can't create a new generic structure every time
a entry comes in. Rather we should leave the generic attr for
cpufreq-dt and do something like this in the cpufreq-dt driver (And
that patch should rather go via cpufreq tree and not ARM SoC)..
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index a5b6a854661f..e229258ad791 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -36,6 +36,12 @@ struct private_data {
unsigned int voltage_tolerance; /* in percentage */
};
+static struct freq_attr *cpufreq_dt_attr[] = {
+ cpufreq_freq_attr_scaling_available_freqs,
+ NULL, /* Extra space for boost-attr if required */
+ NULL,
+};
+
static int set_target(struct cpufreq_policy *policy, unsigned int index)
{
struct dev_pm_opp *opp;
@@ -337,6 +343,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
ret = cpufreq_enable_boost_support();
if (ret)
goto out_free_cpufreq_table;
+ cpufreq_dt_attr[1] = cpufreq_freq_attr_scaling_boost_freqs;
}
policy-cpuinfo.transition_latency = transition_latency;
@@ -412,7 +419,7 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.exit = cpufreq_exit,
.ready = cpufreq_ready,
.name = cpufreq-dt,
- .attr = cpufreq_generic_attr,
+ .attr = cpufreq_dt_attr,
};
static int dt_cpufreq_probe(struct platform_device *pdev)
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
On 07-08-15, 13:13, Krzysztof Kozlowski wrote: Still patches 1/6 and 6/6 need your acks. Is the patch 1/6 a prerequisite for others? It does not look like a prerequisite... but it was put at the beginning of the patchset. Patch 1/6 is required to get boost working, that's all.. Not sure how important is that. Anyway, that will work without 1/6 as well, all you need to do is enable CONFIG_CPU_FREQ_BOOST_SW in you .config. Anyway, it should go via pm tree and can be sent separately. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12
On 03-08-15, 15:55, Bartlomiej Zolnierkiewicz wrote:
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 81064cd..491914c 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -25,6 +25,8 @@ menuconfig ARCH_EXYNOS
select S5P_DEV_MFC
select SRAM
select MFD_SYSCON
+ select THERMAL
+ select EXYNOS_THERMAL
Why do you need to select both of them?
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 77ac021..1c47aee 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -227,6 +227,8 @@ static void __init exynos_init_irq(void)
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = samsung,exynos3250, .data = cpufreq-dt },
{ .compatible = samsung,exynos4210, .data = cpufreq-dt },
+ { .compatible = samsung,exynos4212, .data = cpufreq-dt },
+ { .compatible = samsung,exynos4412, .data = cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-dt },
{ /* sentinel */ }
};
Otherwise looks fine:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12
On 03-08-15, 12:36, Bartlomiej Zolnierkiewicz wrote: I would really like it to be dependency not an option (+ I think that ideally it should be checked at runtime, IOW we should be checking from cpufreq-dt driver if the thermal support is enabled before enabling boost support). I don't think boost has any dependency on thermal support. Yeah, it may be true for your platform but we can't force it. People might have different algorithms to control boost modes, thermal is just one option they may look at. For few, enabling boost may not be a thermal issue, but power. So, they want to allow it only when they want, but that wouldn't burn their chip. So, a platform can choose how it wants to have it. :) -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12
On 03-08-15, 12:17, Bartlomiej Zolnierkiewicz wrote: Hi, On Saturday, August 01, 2015 04:47:21 PM Viresh Kumar wrote: On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote: diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 659879a..bf6d596 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -191,6 +191,7 @@ config CPUFREQ_DT # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y: depends on !CPU_THERMAL || THERMAL select PM_OPP + select EXYNOS_THERMAL if ARCH_EXYNOS help This adds a generic DT based cpufreq driver for frequency management. It supports both uniprocessor (UP) and symmetric multiprocessor (SMP) No, we shouldn't pollute generic Kconfig options with platform specific stuff. The old code depended on this. You couldn't enable boost support without enabling thermal support (ARM_EXYNOS_CPU_FREQ_BOOST_SW config option selected EXYNOS_THERMAL). Why don't you enable thermal in your .config? It is enabled in exynos_defconfig but without the above change it can disabled manually which is something that we don't want. You are not getting it. I am not asking you to not select thermal, but to select it from within your architecture Kconfig option if you want. Over that, thermal is really an option, not a dependency. So, if someone manually disables it, its his problem not yours :) -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] cpufreq: remove no longer needed CPU_FREQ_BOOST_SW config option
On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
Remove no longer needed CPU_FREQ_BOOST_SW config option.
As a result scaling_boost_freqs sysfs attribute is available
when cpufreq-dt driver is used and boost support is enabled.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Thomas Abraham thomas...@samsung.com
Cc: Javier Martinez Canillas jav...@osg.samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/cpufreq/Kconfig | 4
drivers/cpufreq/freq_table.c | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index bf6d596..de00a52 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -21,10 +21,6 @@ if CPU_FREQ
config CPU_FREQ_GOV_COMMON
bool
-config CPU_FREQ_BOOST_SW
- bool
- depends on THERMAL
-
config CPU_FREQ_STAT
tristate CPU frequency translation statistics
default y
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index a8f1daf..4c5de5b 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -293,9 +293,7 @@ EXPORT_SYMBOL_GPL(cpufreq_freq_attr_scaling_boost_freqs);
struct freq_attr *cpufreq_generic_attr[] = {
cpufreq_freq_attr_scaling_available_freqs,
-#ifdef CONFIG_CPU_FREQ_BOOST_SW
cpufreq_freq_attr_scaling_boost_freqs,
-#endif
NULL,
};
EXPORT_SYMBOL_GPL(cpufreq_generic_attr);
So, this will start appearing for all platforms that use cpufreq_generic_attr
and that may not be the right thing. We may only want to show boost frequencies
only if the driver supports it.
@Rafael: What do you say?
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12
On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote: diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 659879a..bf6d596 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -191,6 +191,7 @@ config CPUFREQ_DT # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y: depends on !CPU_THERMAL || THERMAL select PM_OPP + select EXYNOS_THERMAL if ARCH_EXYNOS help This adds a generic DT based cpufreq driver for frequency management. It supports both uniprocessor (UP) and symmetric multiprocessor (SMP) No, we shouldn't pollute generic Kconfig options with platform specific stuff. Why don't you enable thermal in your .config? -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] ARM: dts: Exynos4x12: add CPU OPP and regulator supply property
On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
For Exynos4x12 platforms, add CPU operating points (using
opp-v2 bindings) and CPU regulator supply properties for
migrating from Exynos specific cpufreq driver to using
generic cpufreq driver.
Based on the earlier work by Thomas Abraham.
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Andreas Faerber afaer...@suse.de
Cc: Thomas Abraham thomas...@samsung.com
Reviewed-by: Javier Martinez Canillas jav...@osg.samsung.com
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/boot/dts/exynos4212.dtsi | 81
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 ++
arch/arm/boot/dts/exynos4412-origen.dts | 4 ++
arch/arm/boot/dts/exynos4412-trats2.dts | 4 ++
arch/arm/boot/dts/exynos4412.dtsi | 83
+
5 files changed, 176 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index d9c8efee..5389011 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -30,6 +30,9 @@
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0xA00;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ operating-points-v2 = cpu0_opp_table;
cooling-min-level = 13;
cooling-max-level = 7;
#cooling-cells = 2; /* min followed by max */
@@ -39,6 +42,84 @@
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0xA01;
+ operating-points-v2 = cpu0_opp_table;
+ };
+ };
+
+ cpu0_opp_table: opp_table0 {
+ compatible = operating-points-v2;
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 2;
+ opp-microvolt = 90;
+ clock-latency-ns = 20;
+ };
+ opp01 {
+ opp-hz = /bits/ 64 3;
+ opp-microvolt = 90;
+ clock-latency-ns = 20;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 4;
+ opp-microvolt = 925000;
+ clock-latency-ns = 20;
+ };
+ opp03 {
+ opp-hz = /bits/ 64 5;
+ opp-microvolt = 95;
+ clock-latency-ns = 20;
+ };
+ opp04 {
+ opp-hz = /bits/ 64 6;
+ opp-microvolt = 975000;
+ clock-latency-ns = 20;
+ };
+ opp05 {
+ opp-hz = /bits/ 64 7;
+ opp-microvolt = 987500;
+ clock-latency-ns = 20;
+ };
+ opp06 {
+ opp-hz = /bits/ 64 8;
+ opp-microvolt = 100;
+ clock-latency-ns = 20;
+ };
+ opp07 {
+ opp-hz = /bits/ 64 9;
+ opp-microvolt = 1037500;
+ clock-latency-ns = 20;
+ };
+ opp08 {
+ opp-hz = /bits/ 64 10;
+ opp-microvolt = 1087500;
+ clock-latency-ns = 20;
+ };
+ opp09 {
+ opp-hz = /bits/ 64 11;
+ opp-microvolt = 1137500;
+ clock-latency-ns = 20;
+ };
+ opp10 {
+ opp-hz = /bits/ 64 12;
+ opp-microvolt = 1187500;
+ clock-latency-ns = 20;
+ };
+ opp11 {
+ opp-hz = /bits/ 64 13;
+ opp-microvolt = 125;
+ clock-latency-ns = 20;
+ };
+ opp12 {
+ opp-hz = /bits/ 64 14;
+ opp-microvolt = 1287500;
+ clock-latency-ns = 20;
+ };
+ opp13 {
+ opp-hz = /bits/ 64 15;
+ opp-microvolt = 135;
+ clock-latency-ns = 20;
+ turbo-mode;
};
};
};
I'm lovin' it :)
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
Re: [PATCH v3 4/5] cpufreq: exynos: remove Exynos4x12 specific cpufreq driver support
Cc'ing Rafael, please keep him in loop for such patches and better use get_maintainers to get the cc list automatically. On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote: Exynos4x12 based platforms have switched over to use generic cpufreq driver for cpufreq functionality. So the Exynos specific cpufreq support for these platforms can be removed. Also once Exynos4x12 based platforms support have been removed the shared exynos-cpufreq driver is no longer needed and can be deleted. Based on the earlier work by Thomas Abraham. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Thomas Abraham thomas...@samsung.com Reviewed-by: Javier Martinez Canillas jav...@osg.samsung.com Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/cpufreq/Kconfig.arm | 38 -- drivers/cpufreq/Makefile | 2 - drivers/cpufreq/exynos-cpufreq.c | 236 --- drivers/cpufreq/exynos-cpufreq.h | 72 --- drivers/cpufreq/exynos4x12-cpufreq.c | 236 --- 5 files changed, 584 deletions(-) delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c Acked-by: Viresh Kumar viresh.ku...@linaro.org -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes
On 27-07-15, 13:14, Bartlomiej Zolnierkiewicz wrote: Sorry but you don't seem to understand the issue. :) No, I did. I understand that if someone uses opp bindings today with some entries as turbo OPPs, cpufreq will use them as normal frequencies. And that may harm the board. BUT, opp-v2 code isn't ready to be used yet. And platforms should see what all is implemented before trying to use them. All I was saying is, this isn't a FIX as we haven't introduced the feature yet. Otherwise I had no issues with the patch. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] cpufreq-dt: add turbo modes support
On 27-07-15, 13:58, Bartlomiej Zolnierkiewicz wrote: Thank you. This is exactly the case here (I would like to get Exynos4x12 conversion to use cpufreq-dt + exynos-cpufreq removal in v4.3 if possible and adding new DT bindings will most likely slow down the process considerably). Heh, I never asked you to add new DT bindings, I said we can solve it with DT. We already have turbo properties in DT. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] cpufreq-dt: add turbo modes support
On 27-07-15, 13:01, Bartlomiej Zolnierkiewicz wrote: First of all, please don't be angry :).. We can discuss and get things sorted out ... This change was in the original patch posted in April: https://lkml.org/lkml/2015/4/10/646 Yeah, and I already apologized for missing the request :) your review from a month ago didn't contain this request: https://lkml.org/lkml/2015/6/22/667 Your patch inserted almost 116 lines and most of the stuff was around adding new bindings to get things working with cpufreq-dt driver. And so I replied to the most important stuff, i.e. don't add new bindings, we will sort it out with opp-v2. And frankly that wasn't the time where we could have discussed how exactly we are going to use it. Ofcourse we should get it via DT, platform data is just not required. So, me not NAK ing this approach was fine as it wasn't about keeping this data in the platform data part. and now (after nearly 4 months) you are telling me that I will say a month, as we discarded most of that patch recently :) I should change this because you are planning to do some more changes in the future. Its not about me doing some changes. But the whole point of doing the opp-v2 thing was to get rid of such platform data things.. Just that your work is competing with opp-v2 code :) Could we please keep it as it is for now and change it later (after independent_clocks configuration will get ported to use device tree)? I thought we can get your work to a better shape, with all credit to you. But if you have some dependency on this for 4.3, then I don't mind killing this structure after you have polluted it a bit more :) -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes
$subject is a bit wrong, we aren't fixing any issue here. We are supporting a new feature and so it should be like: cpufreq: Mark boost frequencies based on OPP's turbo mode On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote: Turbo modes should be marked with CPUFREQ_BOOST_FREQ flag in the frequency table entry. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Michael Turquette mturque...@baylibre.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Thomas Abraham thomas...@samsung.com Cc: Viresh Kumar viresh.ku...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/cpufreq/cpufreq_opp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c index 773bcde..f0cf502 100644 --- a/drivers/cpufreq/cpufreq_opp.c +++ b/drivers/cpufreq/cpufreq_opp.c @@ -75,6 +75,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev, } freq_table[i].driver_data = i; freq_table[i].frequency = rate / 1000; + if (dev_pm_opp_get_turbo_mode_setting(opp) == true) + freq_table[i].flags |= CPUFREQ_BOOST_FREQ; } freq_table[i].driver_data = i; Rest look fine. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] opp: add dev_pm_opp_get_turbo_mode_setting() helper
On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote: +bool dev_pm_opp_get_turbo_mode_setting(struct dev_pm_opp *opp) This should be named dev_pm_opp_is_turbo(). -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] cpufreq-dt: add turbo modes support
On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
diff --git a/include/linux/cpufreq-dt.h b/include/linux/cpufreq-dt.h
index 0414009..483ca1b 100644
--- a/include/linux/cpufreq-dt.h
+++ b/include/linux/cpufreq-dt.h
@@ -17,6 +17,7 @@ struct cpufreq_dt_platform_data {
* clock.
*/
bool independent_clocks;
+ bool boost_supported;
};
I am planning to kill this structure soon, don't add anything to it.
We should be doing this based on DT.
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
On 01-07-15, 15:10, Bartlomiej Zolnierkiewicz wrote: This patch series removes the use of Exynos5250 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform. This patch series has been tested on Exynos5250 based Arndale board. Changes since v1 (http://lkml.org/lkml/2015/4/13/611): - rebased on top of next-20150629 branch of linux-next kernel tree - dropped dependency on [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform patch series as it needs more work (Viresh has requested porting of cpufreq-dt's boost mode support over opp-v2 patches) Changes since v2 (http://lkml.org/lkml/2015/6/29/361): - put the new cpu nodes in alphabetical order - updated Javier's and Mike's e-mail adresses - removed Cc: tag with stale Sachin's e-mail adress - added Reviewed-by: tag from Krzysztof to patches #3 and #4 Acked-by: Viresh Kumar viresh.ku...@linaro.org -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
Hi Bartlomiej, [Adding Rafael Rob to cc list. Please don't forget for any PM specific patches :)] First of all, really sorry for missing this mail thread. Don't know how I missed it though. And please please please, do send a ping reminder (to me at least), if you think the mail thread is missed/ignored by the Maintainers. Its been two months, and not a single reminder :).. And I wouldn't have seen this email if you wouldn't have pinged me on IRC .. On 10-04-15, 19:58, Bartlomiej Zolnierkiewicz wrote: This patch series removes the use of Exynos4x12 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform. Excellent. In order to preserve support for Exynos4x12 'boost' mode cpufreq-dt driver is made aware of 'boost' mode frequencies and boost-opps binding is provided. That's good too.. boost-opps binding is currently limited to cpufreq-dt but once there is a need for cpufreq wide and/or generic Linux device support for 'boost' mode cpufreq-dt can be updated to handle the new code without changing the binding itself. You already know that operating-points-v2 bindings are already accepted and applied by Rafael. Its not that the earlier bindings are discarded or obsolete now, but are only present for simple use cases. There are NO plans for extending the earlier OPP bindings Unless its really required. And what you are trying to do in cpufreq-dt's bindings, really belongs to OPP bindings. As the new bindings will be present in 4.2, getting the code (at least the basic code) for them into 4.3 wouldn't be that difficult. Anyway, your stuff isn't going out in 4.2 either and so you *shall* adopt to opp-v2 bindings in your next version. Migrating platforms to opp-v2 wouldn't be that difficult, mostly changes required only in dts files, unless you are using a driver of your own. I would be updating cpufreq-dt at the earlier to support basic features of opp-v2 for 4.3. Some code is already posted: http://permalink.gmane.org/gmane.linux.power-management.general/61326 -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
Re: [PATCH 06/41] clocksource: exynos_mct: Migrate to new 'set-state' interface
Hi Alexey,
On 18-06-15, 19:38, Alexey Klimov wrote:
(adding samsung list and Krzysztof to c/c)
Thanks.
Please don't forget to send patches to platform list and platform maintainers.
Hmmm, I cc'd Kukjin on this patch as he was the one Acking most of the
patches on this driver recently (had a look at git log). Also looked
at MAINTAINERS and the driver itself to look for maintainers, and
kukjin was all I can find. Yes, get_maintainers gave the two names you
added, but many a times it generates list longer than required and so
I don't completely depend on that.
Anyway, thanks.
On Thu, Jun 18, 2015 at 1:54 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
+static int set_state_shutdown(struct clock_event_device *evt)
+{
+ exynos4_mct_tick_stop(this_cpu_ptr(percpu_mct_tick));
Let me clarify the purpose of this patch and the series.
Its only about breaking the older -set_mode() callback into state
based callbacks and not change the way things were done. And so no
improvements in this patch. If there are improvements possible on the
driver, then they must be done separately.
Passed evt pointer isn't used
Its a callback from clockevents core, and we can't get rid of the
argument. :)
and instead you're going to locate
percpu_mct_tick struct knowing current cpu number offset.
That's the way -set_mode() was doing it and so I didn't touched it to
keep this patch simple.
What do you think, since evt is embedded into percpu_mct_tick
structure then maybe it will be cheaper to calculate percpu_mct_tick
using container_of()?
struct mct_clock_event_device *mevt;
mevt = container_of(evt, struct mct_clock_event_device, evt);
Ofcourse, but that has to be fixed for many routines and should be
done in a separate patch. It doesn't belong to this one.
@@ -455,7 +447,10 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
evt-name = mevt-name;
evt-cpumask = cpumask_of(cpu);
evt-set_next_event = exynos4_tick_set_next_event;
- evt-set_mode = exynos4_tick_set_mode;
+ evt-set_state_periodic = set_state_periodic;
+ evt-set_state_shutdown = set_state_shutdown;
+ evt-set_state_oneshot = set_state_shutdown;
+ evt-tick_resume = set_state_shutdown;
Do i correctly understand that during massive hot-plug cpu events (i
guess that will lead to CPU_STARING notification) on power management
this *_timer_setup() function will be called?
I hope so.
And here code performs setting of rather constant values and copying.
You're going to increase number of such strange assignments.
Well, just lazy-thinking. Can we do something like this:
for_each_possible_cpu(cpu) {
exynos4_local_timer_setup_prepare(per_cpu(percpu_mct_tick,
cpu).evt, cpu);
}
somewhere in exynos_mct init functions and assign most of these values
for each evt structure?
And make *_timer_setup() function lighter moving some code to
prepare/init functions.
I agree.. But again, that has to be done in a separate patch.
If it makes any sense i can take a look and try to prepare patch.
Sure..
Do you need testers? I can test it on odroid-xu3.
That will be good.
Can't find in emails similar patch for ARM arch timer. Any plans about
it? Or if it's already converted to 'set-state' then could you please
share a link?
https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/4.3
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/cpufreq: include module.h for modular exynos-cpufreq.c code
On 03-06-15, 17:18, Paul Gortmaker wrote: This file is built off of a tristate Kconfig option (ARM_EXYNOS_CPUFREQ) and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during pending header shuffles. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [ patch will be appended to the implicit include fixup series, see: https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com for the original series posting.] drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 82d2fbb20f7e..4c157302365f 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -10,6 +10,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/err.h #include linux/clk.h #include linux/io.h Acked-by: Viresh Kumar viresh.ku...@linaro.org -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
On 25-05-15, 07:39, Shailendra Verma wrote:
During probe free the memory allocated to exynos_info in case of
unknown SOC type.
Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com
---
drivers/cpufreq/exynos-cpufreq.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 82d2fbb..8682378 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -182,7 +182,7 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
ret = exynos5250_cpufreq_init(exynos_info);
} else {
pr_err(%s: Unknown SoC type\n, __func__);
- return -ENODEV;
+ ret = -ENODEV;
}
if (ret)
@@ -190,12 +190,14 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
if (exynos_info-set_freq == NULL) {
dev_err(pdev-dev, No set_freq function (ERR)\n);
+ ret = -EINVAL;
goto err_vdd_arm;
}
arm_regulator = regulator_get(NULL, vdd_arm);
if (IS_ERR(arm_regulator)) {
dev_err(pdev-dev, failed to get resource vdd_arm\n);
+ ret = -EINVAL;
goto err_vdd_arm;
}
@@ -227,7 +229,7 @@ err_cpufreq_reg:
regulator_put(arm_regulator);
err_vdd_arm:
kfree(exynos_info);
- return -EINVAL;
+ return ret;
}
static struct platform_driver exynos_cpufreq_platdrv = {
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
On 21-05-15, 23:59, Shailendra Verma wrote:
During probe free the memory allocated to exynos_info in case of unknown
SOC type.
Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com
---
drivers/cpufreq/exynos-cpufreq.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 82d2fbb..b77923a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -182,6 +182,7 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
ret = exynos5250_cpufreq_init(exynos_info);
} else {
pr_err(%s: Unknown SoC type\n, __func__);
+ kfree(exynos_info);
return -ENODEV;
}
There is no point replicating this stuff. Use labels like: err_vdd_arm
to get this done. But you also need to make sure the right error gets
propagated.
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] cpufreq: arm_big_little: add cluster regulator support
On 21 April 2015 at 18:47, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Add cluster regulator support as a preparation to adding
generic arm_big_little_dt cpufreq_dt driver support for
ODROID-XU3 board. This allows arm_big_little[_dt] driver
This is irrelevant here, its not about XU3 but any board that
wants to use it..
to set not only the frequency but also the voltage (which
is obtained from operating point's voltage value) for CPU
clusters.
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Andreas Faerber afaer...@suse.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
.../bindings/cpufreq/arm_big_little_dt.txt |4 +
drivers/cpufreq/arm_big_little.c | 153
+---
2 files changed, 139 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
index 0715695..8ca4a12 100644
--- a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -18,6 +18,10 @@ Required properties:
Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
+- cpu-cluster.0-supply: Provides the regulator node supplying voltage to CPU
+ cluster 0.
+- cpu-cluster.1-supply: Provides the regulator node supplying voltage to CPU
+ cluster 1.
I don't think you need these..
http://permalink.gmane.org/gmane.linux.power-management.general/58548
Examples:
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index e1a6ba6..edb461b 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -31,6 +31,7 @@
#include linux/slab.h
#include linux/topology.h
#include linux/types.h
+#include linux/regulator/consumer.h
#include asm/bL_switcher.h
#include arm_big_little.h
@@ -54,6 +55,9 @@ static bool bL_switching_enabled;
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
+static struct regulator *reg[MAX_CLUSTERS];
+static struct device *cpu_devs[MAX_CLUSTERS];
+static int transition_latencies[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
static atomic_t cluster_usage[MAX_CLUSTERS + 1];
@@ -122,7 +126,76 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
}
}
-static unsigned int
+static int
+bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
+{
+ unsigned long volt = 0, volt_old = 0;
+ long freq_Hz;
+ u32 old_rate;
+ int ret;
+
+ freq_Hz = new_rate * 1000;
+ old_rate = clk_get_rate(clk[cluster]) / 1000;
+
+ if (!IS_ERR(reg[cluster])) {
+ struct dev_pm_opp *opp;
+ unsigned long opp_freq;
+
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster], freq_Hz);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err(%s: cpu %d, cluster: %d, failed to find OPP
for %ld\n,
+ __func__, cpu, cluster, freq_Hz);
+ return PTR_ERR(opp);
+ }
+ volt = dev_pm_opp_get_voltage(opp);
+ opp_freq = dev_pm_opp_get_freq(opp);
+ rcu_read_unlock();
+ volt_old = regulator_get_voltage(reg[cluster]);
+ pr_debug(%s: cpu %d, cluster: %d, Found OPP: %ld kHz, %ld
uV\n,
+ __func__, cpu, cluster, opp_freq / 1000, volt);
+ }
+
+ pr_debug(%s: cpu %d, cluster: %d, %u MHz, %ld mV -- %u MHz, %ld
mV\n,
+ __func__, cpu, cluster,
+ old_rate / 1000, (volt_old 0) ? volt_old / 1000 : -1,
+ new_rate / 1000, volt ? volt / 1000 : -1);
+
+ /* scaling up? scale voltage before frequency */
+ if (!IS_ERR(reg[cluster]) new_rate old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
+ if (ret) {
+ pr_err(%s: cpu: %d, cluster: %d, failed to scale
voltage up: %d\n,
+ __func__, cpu, cluster, ret);
+ return ret;
+ }
+ }
+
+ ret = clk_set_rate(clk[cluster], new_rate * 1000);
+ if (WARN_ON(ret)) {
+ pr_err(%s: clk_set_rate failed: %d, cluster: %d\n,
+ __func__, cluster, ret);
+ if (!IS_ERR(reg[cluster]) volt_old 0)
+ regulator_set_voltage_tol(reg[cluster], volt_old, 0);
+ return ret;
+
Re: [PATCH] cpufreq: exynos: remove dead -need_apll_change method
On 27 March 2015 at 22:02, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Commit 26ab1c62b6e1 (cpufreq: exynos5250: Set APLL rate using CCF API) removed the last user of -need_apll_change method. Remove it and then cleanup exynos_cpufreq_scale() accordingly. This patch was tested on Exynos4412 SoC based Trats2 board. There should be no functional changes caused by this patch. Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Lukasz Majewski l.majew...@samsung.com Cc: Kukjin Kim kg...@kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/cpufreq/exynos-cpufreq.c | 30 +++--- drivers/cpufreq/exynos-cpufreq.h |1 - 2 files changed, 3 insertions(+), 28 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org @Kukjin: please take it through your tree. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: allow build for !THERMAL or !CPU_THERMAL cases
On 23 March 2015 at 22:13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Would you pick this patch up or should I resend it to Rafael? Please resend it to Rafael and cc me and linux-pm list.. Also add my Ack to it. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: allow build for !THERMAL or !CPU_THERMAL cases
On 20 February 2015 at 21:50, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Allow driver build for !THERMAL or !CPU_THERMAL cases. The new dependency rule is the same as the one that CPUFREQ_DT option has (for cpufreq-dt driver which has the same issue with using of_cpufreq_cooling_register()). Cc: Kukjin Kim kg...@kernel.org Cc: Arnd Bergmann a...@arndb.de Cc: Eduardo Valentin edubez...@gmail.com Cc: Lukasz Majewski l.majew...@samsung.com Fixes: 8b2b4a4e5366 (cpufreq: exynos: allow modular build) Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- drivers/cpufreq/Kconfig.arm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 1b06fc4..f4df4af3 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -28,7 +28,8 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ tristate SAMSUNG EXYNOS CPUfreq Driver depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250 - depends on THERMAL + # if CPU_THERMAL is on and THERMAL=m, ARM_EXYNOS_CPUFREQ cannot be =y: + depends on !CPU_THERMAL || THERMAL help This adds the CPUFreq driver for Samsung EXYNOS platforms. Supported SoC versions are: Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/1] cpufreq: exynos: allow modular build
On 1 February 2015 at 00:29, Eduardo Valentin edubez...@gmail.com wrote: From: Arnd Bergmann a...@arndb.de The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 (cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered) Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Eduardo Valentin edubez...@gmail.com --- drivers/cpufreq/Kconfig.arm | 44 ++-- drivers/cpufreq/Makefile| 9 + 2 files changed, 31 insertions(+), 22 deletions(-) --- Changes from V1: - Instead of having several modules, the driver now is constructed by several files into a single module, depending on config. - The patch does not change existing user defconfigs. If no objections, I will include this in into my -fixes branch. Cheers, Eduardo Valentin diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 0f9a2c3..1b06fc4 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ - bool + tristate SAMSUNG EXYNOS CPUfreq Driver + depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250 + depends on THERMAL + help + This adds the CPUFreq driver for Samsung EXYNOS platforms. + Supported SoC versions are: +Exynos4210, Exynos4212, Exynos4412, and Exynos5250. + + If in doubt, say N. config ARM_EXYNOS4210_CPUFREQ bool SAMSUNG EXYNOS4210 depends on CPU_EXYNOS4210 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4210 SoC (S5PV310 or S5PC210). @@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ config ARM_EXYNOS4X12_CPUFREQ bool SAMSUNG EXYNOS4x12 depends on SOC_EXYNOS4212 || SOC_EXYNOS4412 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4X12 SoC (EXYNOS4212 or EXYNOS4412). @@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ config ARM_EXYNOS5250_CPUFREQ bool SAMSUNG EXYNOS5250 depends on SOC_EXYNOS5250 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS5250 SoC. If in doubt, say N. -config ARM_EXYNOS5440_CPUFREQ - bool SAMSUNG EXYNOS5440 - depends on SOC_EXYNOS5440 - depends on HAVE_CLK OF - select PM_OPP - default y - help - This adds the CPUFreq driver for Samsung EXYNOS5440 - SoC. The nature of exynos5440 clock controller is - different than previous exynos controllers so not using - the common exynos framework. - - If in doubt, say N. - config ARM_EXYNOS_CPU_FREQ_BOOST_SW bool EXYNOS Frequency Overclocking - Software depends on ARM_EXYNOS_CPUFREQ THERMAL @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW If in doubt, say N. +config ARM_EXYNOS5440_CPUFREQ + tristate SAMSUNG EXYNOS5440 + depends on SOC_EXYNOS5440 + depends on HAVE_CLK OF + select PM_OPP + default y + help + This adds the CPUFreq driver for Samsung EXYNOS5440 + SoC. The nature of exynos5440 clock controller is + different than
Re: [PATCH 3/3] cpufreq: exynos: allow modular build
On 29 January 2015 at 15:31, Arnd Bergmann a...@arndb.de wrote: That might be close enough to what we want. It would by default enable ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver (e.g. 5440, which has a separate driver, or exynos3/exynos7), but that can probably just be dealt with by disabling it in the user's defconfig. If i'm reading exynos_cpufreq_probe right, it would actually compile into an almost-empty file in this case and only kzalloc a few bytes of memory and then print a warning message. I may be wrong this time around, but I will still try hard : diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index b3ca7b0b2c33..91747c411d86 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -51,10 +51,9 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos-cpufreq.o exynos4210-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos-cpufreq.o exynos4x12-cpufreq.o +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos-cpufreq.o exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback
On 28 January 2015 at 18:46, Arnd Bergmann a...@arndb.de wrote:
Commit 32726d2d550 (ARM: SAMSUNG: Remove legacy clock code)
already removed the callback pointer, but there was one remaining
user:
drivers/cpufreq/s3c24xx-cpufreq.c: In function 's3c_cpufreq_resume_clocks':
drivers/cpufreq/s3c24xx-cpufreq.c:149:14: error: 'struct s3c_cpufreq_info'
has no member named 'resume_clocks'
cpu_cur.info-resume_clocks();
^
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 32726d2d550 (ARM: SAMSUNG: Remove legacy clock code)
Cc: sta...@vger.kernel.org # v3.17+
---
drivers/cpufreq/s3c24xx-cpufreq.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c
b/drivers/cpufreq/s3c24xx-cpufreq.c
index bd340a1ca87d..733aa5153e74 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -144,11 +144,6 @@ static void s3c_cpufreq_setfvco(struct
s3c_cpufreq_config *cfg)
(cfg-info-set_fvco)(cfg);
}
-static inline void s3c_cpufreq_resume_clocks(void)
-{
- cpu_cur.info-resume_clocks();
-}
-
static inline void s3c_cpufreq_updateclk(struct clk *clk,
unsigned int freq)
{
@@ -417,9 +412,6 @@ static int s3c_cpufreq_resume(struct cpufreq_policy
*policy)
last_target = ~0; /* invalidate last_target setting */
- /* first, find out what speed we resumed at. */
- s3c_cpufreq_resume_clocks();
-
/* whilst we will be called later on, we try and re-set the
* cpu frequencies as soon as possible so that we do not end
* up resuming devices and then immediately having to re-set
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] cpufreq: exynos: allow modular build
On 29 January 2015 at 01:31, Arnd Bergmann a...@arndb.de wrote: config ARM_EXYNOS_CPUFREQ - bool + tristate SAMSUNG EXYNOS CPUfreq Driver + depends on THERMAL + default y + help + This adds the CPUFreq driver for Samsung EXYNOS platforms + + If in doubt, say N. Now the option shows up on all systems that include Kconfig.arm, in particular non-exynos machines that might not even be able to build this. I am sure I am wrong here, but want to know what I am missing. What about: diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index c3c3cf52d2d9..f3ee05067a69 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ tristate SAMSUNG EXYNOS CPUfreq Driver - depends on THERMAL + depends on THERMAL ARCH_EXYNOS default y help This adds the CPUFreq driver for Samsung EXYNOS platforms -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
On 26 January 2015 at 14:55, Lukasz Majewski l.majew...@samsung.com wrote:
Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided possibility to
use device tree to asses if cpu can be used as cooling device. Since the
code was somewhat awkward, simpler approach has been proposed.
Test HW: Exynos 4412 - Odroid U3.
Suggested-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 5e98c6b..b640da0 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
static int exynos_cpufreq_probe(struct platform_device *pdev)
{
- struct device_node *cpus, *np;
+ struct device_node *cpu0, *np;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
if (ret)
goto err_cpufreq_reg;
- cpus = of_find_node_by_path(/cpus);
- if (!cpus) {
- pr_err(failed to find cpus node\n);
+ cpu0 = of_get_cpu_node(0, NULL);
+ if (!cpu0) {
+ pr_err(failed to find cpu0 node\n);
return 0;
}
- np = of_get_next_child(cpus, NULL);
- if (!np) {
- pr_err(failed to find cpus child node\n);
- of_node_put(cpus);
- return 0;
- }
-
- if (of_find_property(np, #cooling-cells, NULL)) {
- cdev = of_cpufreq_cooling_register(np,
+ if (of_find_property(cpu0, #cooling-cells, NULL)) {
+ cdev = of_cpufreq_cooling_register(cpu0,
cpu_present_mask);
if (IS_ERR(cdev))
pr_err(running cpufreq without cooling device:
%ld\n,
PTR_ERR(cdev));
}
- of_node_put(np);
- of_node_put(cpus);
return 0;
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 08/18] cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered
On 23 January 2015 at 17:44, Lukasz Majewski l.majew...@samsung.com wrote:
+ cpus = of_find_node_by_path(/cpus);
+ if (!cpus) {
+ pr_err(failed to find cpus node\n);
+ return 0;
+ }
+
+ np = of_get_next_child(cpus, NULL);
+ if (!np) {
+ pr_err(failed to find cpus child node\n);
+ of_node_put(cpus);
return 0;
+ }
Why making it complex? Just get device node for cpu 0 and
do cpu_dev-np.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
On 21 January 2015 at 14:03, Lukasz Majewski l.majew...@samsung.com wrote:
diff --git a/drivers/cpufreq/exynos-cpufreq.c
static int exynos_cpufreq_probe(struct platform_device *pdev)
{
+ struct device_node *cpus, *np;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct
platform_device *pdev) /* Done here as we want to capture boot
frequency */ locking_frequency = clk_get_rate(exynos_info-cpu_clk) /
1000;
- if (!cpufreq_register_driver(exynos_driver))
- return 0;
+ if (cpufreq_register_driver(exynos_driver))
You should return the error returned by cpufreq_register_driver().
+ goto err;
+ cpus = of_find_node_by_path(/cpus);
+ if (!cpus) {
+ pr_err(failed to find cpus node\n);
+ return -ENOENT;
+ }
+
+ for (np = of_get_next_child(cpus, NULL); np;
+ of_node_put(np), np = of_get_next_child(cpus, np)) {
+ if (of_find_property(np, #cooling-cells, NULL)) {
Shouldn't you be checking this just for cpu 0 ?
+ cdev = of_cpufreq_cooling_register(np,
+
cpu_present_mask);
+ if (IS_ERR(cdev))
+ pr_err(running cpufreq without
cooling device: %ld\n,
+PTR_ERR(cdev));
+ break;
+ }
+ }
+ of_node_put(np);
+ of_node_put(cpus);
+
+ return 0;
+ err:
dev_err(pdev-dev, failed to register cpufreq driver\n);
regulator_put(arm_regulator);
err_vdd_arm:
Viresh, the above is a small part of the cpufreq related code, which is
necessary for Exynos thermal rework to use device tree.
It is NOT adding any new functionality, but preserves possibility to
use cpufreq as a colling device.
Normally I would exclude this part from this commit, but then I cannot
assure that between commits no regression is slipping in.
Mostly looks fine. Just few nits.
But another important thing is to split this patch, so that there is a separate
patch for cpufreq driver.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
On 21 January 2015 at 15:17, Lukasz Majewski l.majew...@samsung.com wrote: In previous versions I've only checked for cpu 0. If you think that it is enough to explicitly check only for cpu 0 and forget about above fail safe code (when. e.g. CPU3 has defined cooling-cells), then I'm fine with it. I don't know what bindings are you following, but cpufreq-dt's bindings say that it has to be present in cpu0. Anyway, this driver isn't for a multi-cluster system and so cpu0 should be fine. As I've mention - it would be maintainer's call if one trades potential regression for patch separation. I am just asking it to split into a separate patch, not that I will get it through cpufreq. Eduardo can take it, but it should be a separate patch. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 13:53, Chanwoo Choi cw00.c...@samsung.com wrote:
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)--|--- memory bus for DMC (Dynamic Memory Controller)
block (dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)--|
|--- memory bus for MCUISP block (aclk_400_mcuisp clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
I see..
Please confirm if my understanding is correct.
- mem-bus-group: all blocks sharing a regulator
- mem-bus-block: individual blocks managing their clock rate
What you do in kernel is register group as a device (with virtual OPPs)
and then manage blocks within the driver. And so you need to do this
dummy mapping of virtual to physical frequencies.
It *may* not have done it this way, if I was to design this driver.
Each bus-block is a separately controllable device and so must be registered
separately. In that case all bus-blocks will have separate OPP tables and
all this dummy-v2p mapping will go away.
I believe that you are over complicating stuff without any need..
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 20 January 2015 at 17:07, Chanwoo Choi cw00.c...@samsung.com wrote: If each bus-block has separate regulator independently, each bus-block can be registered separately. But, exynos bus-blocks in mem-bus-group share the same regulator. This can be managed easily within the driver. Just stay the highest voltage requested. I don't think its not manageable. But it will be much more convenient as that will show the correct picture and get rid of unnecessarily virtualizing things.. -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 09:50, Chanwoo Choi cw00.c...@samsung.com wrote:
If the clock will be stayed on highest voltage, will reduce
the considerable benefit of power-consumption.
But this is exactly what you must be doing right now as well..
I think I didn't make it clear enough with an example. Let me
try..
This is how I feel it should look like:
memory_bus_int: memory_bus@1 {
// Regulator is shared for all below
blocks {
peri_block: memory_bus_block1 {
operating-points =
10 85
5 85;
};
display_block: memory_bus_block2 {
operating-points =
20 95
16 95
10 925000
8 85
5 85;
};
isp_block: memory_bus_block3 {
operating-points =
20 95
10 925000
8 85
5 85;
};
gps_block: memory_bus_block4 {
operating-points =
30 95
20 95
133000 925000
10 85
5 85;
};
Now suppose these are the requirements from all the blocks
at any point of time:
- block1: 10 85
- block2: 10 925000
- block3: 8 85
- block4: 133000 925000
Now, all of them can control freq separately and we don't need to
worry for that. But regulator is shared between them. We can check
what's the highest voltage requested at this point of time and can
switch to that.
i.e. 925000 in this case. And that's not the highest possible one.
And you will reach to similar conclusion with your current code as
well I believe.
I think it is DFS instead of DVFS. Is it right?
No. I am still talking about DVFS, V being the highest requested one.
What is the correct picture? do you need more detailed explanation
of Exynos memory bus structure?
The correct picture is what i showed in the above dts example.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 9 January 2015 at 02:48, Rob Herring robherri...@gmail.com wrote:
Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
+ memory_bus_int: memory_bus@1 {
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
So these are the OPPs your groups support and below ones are
the frequencies that each block will support. Right ?
+ blocks {
+ frequency =
+ 10
+ 10
+ 10
+ 10
Why this replication here ?
+ 5
+ 5;
+ };
How are the above two tables (operating-points and frequency) related
here? What about the voltages at which these frequencies are possible ?
+ display_block: memory_bus_block2 {
+ frequency =
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5;
+ };
+ isp_block: memory_bus_block3 {
+ frequency =
+ 20
+ 20
+ 10
+ 8
+ 5
+ 5;
+ };
+ gps_block: memory_bus_block4 {
+ frequency =
+ 30
+ 20
+ 133000
+ 10
+ 5
+ 5;
+ };
same for others as well..
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 01/26] thermal: cpu_cooling: check for the readiness of cpufreq layer
From: Eduardo Valentin edubez...@gmail.com
In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.
Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.
Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
drivers/thermal/cpu_cooling.c | 5 +
drivers/thermal/db8500_cpufreq_cooling.c | 5 -
drivers/thermal/imx_thermal.c | 5 -
drivers/thermal/samsung/exynos_thermal_common.c| 8 +---
drivers/thermal/samsung/exynos_tmu.c | 5 -
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
6 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index ad09e51..f98a763 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -443,6 +443,11 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_frequency_get_table(cpumask_first(clip_cpus))) {
+ pr_debug(%s: CPUFreq table not found\n, __func__);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
*/
#include linux/cpu_cooling.h
-#include linux/cpufreq.h
#include linux/err.h
#include linux/module.h
#include linux/of.h
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
- /* make sure cpufreq driver has been initialized */
- if (!cpufreq_frequency_get_table(0))
- return -EPROBE_DEFER;
-
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
#include linux/clk.h
#include linux/cpu_cooling.h
-#include linux/cpufreq.h
#include linux/delay.h
#include linux/device.h
#include linux/init.h
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
- if (!cpufreq_get_current_driver()) {
- dev_dbg(pdev-dev, no cpufreq driver!);
- return -EPROBE_DEFER;
- }
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index b6be572..50a1f17 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -371,9 +371,11 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
th_zone-cool_dev[th_zone-cool_dev_size] =
cpufreq_cooling_register(mask_val);
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
- dev_err(sensor_conf-dev,
- Failed to register cpufreq cooling device\n);
- ret = -EINVAL;
+ ret =
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
+ if (ret != -EPROBE_DEFER)
+ dev_err(sensor_conf-dev,
+ Failed to register cpufreq cooling
device: %d\n,
+ ret);
goto err_unregister
Re: [PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On 28 November 2014 at 20:23, Eduardo Valentin edubez...@gmail.com wrote: diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c index 1ab0018..88d2775 100644 --- a/drivers/thermal/cpu_cooling.c +++ b/drivers/thermal/cpu_cooling.c @@ -440,6 +440,9 @@ __cpufreq_cooling_register(struct device_node *np, int ret = 0, i; struct cpufreq_policy policy; + if (!cpufreq_frequency_get_table(0)) Please add a pr_debug() here, that will be quite useful while debugging. Also, you can't simply pass 0 to get_table() above. We might be registering the cooling device for some other cluster as well.. This is what I have done in my patch earlier. cpufreq_frequency_get_table(cpumask_first(clip_cpus)); And this will work for all cases. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On 28 November 2014 at 18:44, Eduardo Valentin edubez...@gmail.com wrote: Well, I wouldn't say unfortunately, but fortunately! :-) +1 :) However, I would prefer, at least to what comes to deferring, to update the drivers altogether with the inclusion of the check in cpu cooling. This way the change in behavior is atomic, in terms of commit changes. Viresh, if you don't mind, I will merge your patch 04/26 into this one. Sure, go ahead. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On 27 November 2014 at 19:38, Eduardo Valentin edubez...@gmail.com wrote: Acked-by: Viresh Kumar viresh.ku...@linaro.org Ok. though.. normal practice says ack's are oftern used by the maintainer of the affected code (quoting Documentation/SubmittingPatches) :-) Hehe :) Another paragraph from the same file: Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code. Judgement should be used here. When in doubt people should refer to the original discussion in the mailing list archives. So my Acked-by was as cpufreq subsystem Maintainer :) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
Few nits..
On 26 November 2014 at 23:20, Eduardo Valentin edubez...@gmail.com wrote:
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
The normal practice is to write the non-commitable part here ...
drivers/thermal/cpu_cooling.c | 5 +
drivers/thermal/db8500_cpufreq_cooling.c | 5 -
drivers/thermal/imx_thermal.c | 5 -
drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
5 files changed, 6 insertions(+), 17 deletions(-)
---
But this works as well :)
This is attempt to organize the cpu cooling vs. cpufreq boot sequencing.
The main change in this patch, as in the commit log, is to have the check
for the cpufreq layer in the cpu cooling device registration, instead of
in thermal drivers. This way, drivers don't need to bother about it, they
just need to propagate the error value.
This change was tested on top of:
(0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
https://patchwork.kernel.org/patch/5384141/
https://patchwork.kernel.org/patch/5384151/
https://patchwork.kernel.org/patch/5384161/
https://patchwork.kernel.org/patch/5384171/
(1) - fix of thermal core:
https://patchwork.kernel.org/patch/5326991/
After Viresh's changes, cpufreq-dt is properly sequenced with cpu cooling
registration. Non-of based drivers also should take advantage if these
changes, as now they do not need to check for cpufreq layer. The check is
where it belongs, in cpu cooling device registration.
BR, Eduardo Valentin
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..9e6945b 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_get_current_driver() || !cpufreq_frequency_get_table(0))
{
Only !cpufreq_frequency_get_table(0) is enough here.
For rest:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On 24 November 2014 at 19:14, Sudeep Holla sudeep.ho...@arm.com wrote: On 20/11/14 03:48, Viresh Kumar wrote: - I believe CPUs boot in the order they are present in DT except for the boot CPU. So, the first node for every cluster should have it. Correct ? Then we can update the fixme. No, I disagree as you trying to implicitly depend on the logic Linux uses to assign logical index. It can be changed any time, and depending on it might break things in future which can't be fixed easily later especially if it's DT related. Yeah, correct. Hmm, I never thought about it. But yes the CPU with the OPPs should be the first one to come back. How can you assume that ? I can write a simple test which hot-plugs out all the CPUs in the (esp. multi-cluster) system in ascending order of logical index and hot-plug back in descending order. Then the above logic fails. What I said is: Yes the CPU with the OPPs should be the first one to come back, if this has to work correctly. Otherwise it will break.. And you repeated the same :) The platforms needing it have to get involved in such discussions to make any progress. Yes there were people involved. I hope I cc'd you as well... -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Oh, you are still alive? I thought you were about to get married :) Just kidding !! On 20 November 2014 00:58, Sudeep Holla sudeep.ho...@arm.com wrote: Sorry for raising this issue always with Exynos cpufreq drivers. IMO the bindings for arm-bL-cpufreq-dt is broken. Currently no one is using it and it's better to fix it before we have a real user of it. Hmm, yeah if we can. I haven't found a easy way to go ahead and then got caught in other activities. If you look at the binding document for it[1], it has a fixme which shouldn't have been there at first place. It assumes the ordering of CPU's specified in the DT and the logical index allocation to them. Ok, I believe the FIXME is a bit outdated. From the code I can see only this limitation. - For every cluster, the cpu which boots up first should carry the OPPs. Otherwise there is no restriction on ordering of CPUs. - I believe CPUs boot in the order they are present in DT except for the boot CPU. So, the first node for every cluster should have it. Correct ? Then we can update the fixme. It even breaks for hotplug especially if you hotplug-in back in different order. Hmm, I never thought about it. But yes the CPU with the OPPs should be the first one to come back. We can work around that probably, but it's better to fix the binding. I failed to grab much attention in my previous attempts to address this[2]. Viresh also started a discussion more recently[3]. They are just stuck and went nowhere :( -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
On 20 October 2014 17:11, Thomas Abraham thomas...@samsung.com wrote: Exynos4210 and Exynos5250 based platforms have switched over to use generic cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed. Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Signed-off-by: Thomas Abraham thomas...@samsung.com Acked-by: Viresh Kumar viresh.ku...@linaro.org Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Chander Kashyap k.chan...@samsung.com --- drivers/cpufreq/Kconfig.arm | 22 -- drivers/cpufreq/Makefile|2 -- 2 files changed, 0 insertions(+), 24 deletions(-) Looks like you forgot removing drivers ;) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/4] ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
On 25 September 2014 00:05, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch add exynos3250 compatible string to exynos_cpufreq_matches
for supporting generic cpufreq driver on Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8923d37..1318d69 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -285,6 +285,7 @@ static const struct of_device_id exynos_cpufreq_matches[]
= {
{ .compatible = samsung,exynos5420, .data = arm-bL-cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-cpu0 },
{ .compatible = samsung,exynos4210, .data = cpufreq-cpu0 },
+ { .compatible = samsung,exynos3250, .data = cpufreq-cpu0 },
cpufreq-cpu0 is renamed to cpufreq-dt now.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: s5pv210: Remove spurious __init annotation
On 27 August 2014 16:30, Mark Brown broo...@kernel.org wrote:
From: Mark Brown broo...@linaro.org
Since this is a platform driver and can be probed at any time we can't
annotate funtions in the probe path as __init, the code can't safely be
discarded at the end of kernel init.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/cpufreq/s5pv210-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index 9a68225a757e..3f9791f07b8e 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -501,7 +501,7 @@ static int check_mem_type(void __iomem *dmc_reg)
return val 8;
}
-static int __init s5pv210_cpu_init(struct cpufreq_policy *policy)
+static int s5pv210_cpu_init(struct cpufreq_policy *policy)
{
unsigned long mem_type;
int ret;
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On 25 August 2014 21:26, Tomasz Figa t.f...@samsung.com wrote: Kukjin, Viresh, how would you want to proceed with merging it? It Me and Rafael has agreed earlier that Kukjin can take these through ARM-Soc tree.. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: free memory immediately on unknown SoC
On 17 August 2014 09:36, Arjun Sreedharan arjun...@gmail.com wrote:
Signed-off-by: Arjun Sreedharan arjun...@gmail.com
---
drivers/cpufreq/exynos-cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 1e0ec57..e47d165 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -178,6 +178,7 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
ret = exynos5250_cpufreq_init(exynos_info);
} else {
pr_err(%s: Unknown SoC type\n, __func__);
+ kfree(exynos_info);
return -ENODEV;
}
Apart from the fact that we could have added some logs and improved
$subject a bit,
it looks fine.
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
On 1 August 2014 00:04, Thomas Abraham ta.oma...@gmail.com wrote: You had acked the cpufreq related changes in v7 of this series. But there were some changes in v8 and so I have not included your Ack for v8 and v9. Could you please have one more look at the patches 4/6 [1] and 5/6 [2] of this v9 series and let me know if it looks okay. [1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34865.html [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34864.html Looks fine.. Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
On 23 July 2014 13:08, Lukasz Majewski l.majew...@samsung.com wrote: Do you want to say that we have enough tests and we don't need more ? No. We don't have any tests at all :) I always thought that we shall have as much regression tests as possible. Yeah, tests are welcomed but the question is where should they get added. Don't know if its common to add tests directly to kernel. And also if the test is really good, not discouraging your work. On 21 July 2014 12:32, Lukasz Majewski l.majew...@samsung.com wrote: This commit adds first regression test cpufreq_freq_test.sh for the cpufreq subsystem. That's not enough, Tell us why we should continue reading this mail.. Hmm... If regression and test don't catch the attention of a diligent maintainer, then I cannot do much more to encourage him to read the whole e-mail :-) What I meant to say was, your subject and body must be good enough to answer most of the things. You don't have to tell much about the implementation but other things should be pretty clear from logs. Your current logs are quite short for something that's not a normal practice. I can imagine that maintainers are very busy, therefore I've prepared README file with detailed description of the script operation. Yeah, a README is welcomed and would be useful for users as well.. I couldn't make out the purpose of this test and why we need it. How do we ensure that cpufreq attributes exported by sysfs are exposing correct values? First of all the cpufreq attributes are part of the subsystem API. There are systems which actually depend on them, so we would be better off to test if they work as intended. Secondly, the test takes those values and then with use of other attribute enforce the value, which is then read via cat'ing cpufreq_cur_freq. If any of the attributes is wrong then we will spot the error immediately. Shouldn't you use userspace governor then instead of performance? And then we don't need the gzip stuff at all. We can just set it to the right freq and get current freq to see if it matches? And now that we are starting to get tests added into the kernel (will still wait to see what Rafael has to advice), we better think of the way these are going to get added. Probably a single script with parameters like what to test? And actually what do we mean by this statement even? What kind of errors can be there in exposing these values. Errors with cpufreq and CCF cooperation - especially when some parts of cpufreq code uses direct write to MUX, DIV or PLL SoC registers. Also, one can check if permutations of changing all available frequencies are working properly. Yeah, that would be fine. Probably need to think more about scripts name. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
On 23 July 2014 15:40, Lukasz Majewski l.majew...@samsung.com wrote: Shouldn't you use userspace governor then instead of performance? Performance assures that we will have the right frequency set. Why wouldn't userspace assure that? However, there can be a similar patch to use userspace governor and various load to fail if ondemand's frequency flipping is detected. That's why I want to get to the motive behind this patch. AFAIU, we are checking if its fine to switch to available frequencies or not and if yes, do we actually switch to those. Right? For, this testcase we just need a single test and I still don't see why performance is better than userspace? And then we don't need the gzip stuff at all. We can just set it to the right freq and get current freq to see if it matches? Sometimes interresting things show up when you have 100% CPU load and you try to switch frequency. That's a different test then. And that's how it should be presented. So, probably another option to the script, which isn't forced on people. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
Hi Lukasz, I haven't replied yet as I wanted to see what the general feed of Rafael is going to be :) As this is something new and wasn't sure if we really want this.. On 21 July 2014 12:32, Lukasz Majewski l.majew...@samsung.com wrote: This commit adds first regression test cpufreq_freq_test.sh for the cpufreq subsystem. That's not enough, Tell us why we should continue reading this mail.. Signed-off-by: Lukasz Majewski l.majew...@samsung.com --- Changes for v2: - Replace *_PATCH with *_PATH for variables names - Corrected mistakes in the README file - Providing detailed explanation of the patch in the README file --- drivers/cpufreq/tests/README | 33 +++ drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 + Probably a better place would be tools/power/cpufreq/ @Rafael? 2 files changed, 182 insertions(+) create mode 100644 drivers/cpufreq/tests/README create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README new file mode 100644 index 000..3e9cd80 --- /dev/null +++ b/drivers/cpufreq/tests/README @@ -0,0 +1,33 @@ +This file contains list of cpufreq's available regression tests with a short +usage description. + +1. cpufreq_freq_test.sh + +Description: + +This script is supposed to test if cpufreq attributes exported by sysfs are +exposing correct values. + +To achieve this goal it saves the current governor and changes it to +performance. Afterwards, it reads the scaling_available_frequencies +property. With the list of supported frequencies it is able to enforce each of +them by writing to scaling_max_freq attribute. To make the test more reliable +a superfluous load with gzip is created to be sure that we are running with +highest possible frequency. This high load is regulated with the 'sleep' +duration. After this time the cpufreq_cur_freq is read and compared with the +original value. As the last step the original governor is restored. I couldn't make out the purpose of this test and why we need it. How do we ensure that cpufreq attributes exported by sysfs are exposing correct values? And actually what do we mean by this statement even? What kind of errors can be there in exposing these values. I want to understand the purpose of this script very clearly first and then only will look at the details. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
