, 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
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.
>
>
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 cas
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
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
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
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 @@
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>
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
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:
>
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
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
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
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
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
>
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
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
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 cl
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
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
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
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/bo
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
eq_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
--
end/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:
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
pend() 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 &q
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].
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
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.
orms
> 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:
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
yd <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 ++-
g 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 Szy
esume 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...
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.
-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
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
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
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
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
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,
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
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
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
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
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
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
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
-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
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
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
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
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,
' 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
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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
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 :)
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
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
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.
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
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
, 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
...@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
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
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
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
---
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
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
:
+ 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
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
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
();
-
/* 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
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,
: 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
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)
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 =
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
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
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
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.
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:
+-
...@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
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 @@
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
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
@@ -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
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
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
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
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
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
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
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
] 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
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
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
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
1 - 100 of 236 matches
Mail list logo
