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
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
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:
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
On 06-08-15, 15:41, Bartlomiej Zolnierkiewicz wrote:
> Remove no longer needed CPU_FREQ_BOOST_SW config option.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
&g
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
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_b
gt; 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
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Suggested-by: Viresh Kumar
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 opti
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
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
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Suggested-by: Vires
On 08-08-15, 00:21, Rafael J. Wysocki wrote:
> > Acked-by: Viresh Kumar
>
> 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 separ
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 separatel
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
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Suggested-by: Vir
On 08-08-15, 16:36, Krzysztof Kozlowski wrote:
> The cpufreq driver will be removed completely in v4.3 or v4.4 with
> patchset adding cpufreq-dt support for Exynos 4x12. This means that this
> patch makes sense only for 4.2 and as a stable backport (but it was not
> marked as such).
>
> Anyone thi
On 08-08-15, 16:27, Krzysztof Kozlowski wrote:
> Can you apply the 2-5 of this series to v4.3? It's getting late but
> maybe they still could go?
FWIW, 1/6 (updated version) is already applied by Rafael.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
g on Exynos4412 based Odroid U3
> board.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> This patch supers
esume support on Exynos4412 based
> > Trats2 board and reboot hang on Exynos4412 based Odroid U3
> > board.
> >
> > Cc: Viresh Kumar
> > Cc: Thomas Abraham
> > Cc: Javier Martinez Canillas
> > Cc: Krzysztof Kozlowski
> > Cc: Marek Szyp
That's the naming convention followed in most of opp core, but few
routines didn't follow this, fix them.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
arch/arm/mach-imx/mach-imx6q.c | 2 +-
drivers/base/power/opp.c
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: Pav
On 03-09-15, 20:11, Bartlomiej Zolnierkiewicz wrote:
> Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
>
orms
> which don't require suspend frequency).
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: Bartlomiej Zolnierkiewicz
/resume support on Exynos4412 based
> Trats2 board and reboot hang on Exynos4412 based Odroid U3
> board.
>
> Cc: Viresh Kumar
> Cc: Thomas Abraham
> Cc: Javier Martinez Canillas
> Cc: Krzysztof Kozlowski
> Cc: Marek Szyprowski
> Cc: Tobias Jakobi
> Signed-off-by: B
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
d() 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
--
To unsubscribe from this list: send the line "unsubscribe
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 tre
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
e need to set SLEEP FREQ
> again */
> -#endif
> };
>
> static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
Acked-by: Viresh Kumar
--
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 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
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Signed-off-by: Viresh Kumar
---
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
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 t
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Viresh Kumar
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm
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 tak
On 03-12-15, 11:26, Ben Gamari wrote:
> Viresh Kumar 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
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
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
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 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 s
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 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 othe
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 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, 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
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
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
On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote:
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 48a0a55..616c2d0 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -50,6 +50,116 @@
> usbd
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 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
--
To unsubscrib
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 Krzys
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_o
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 !pr
rrupts, as explained by: commit 8fff52fd5093
("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").
Signed-off-by: Viresh Kumar
---
drivers/clocksource/exynos_mct.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksourc
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
--
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 23 March 2015 at 22:13, Bartlomiej Zolnierkiewicz
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 o
0 +++---
> drivers/cpufreq/exynos-cpufreq.h |1 -
> 2 files changed, 3 insertions(+), 28 deletions(-)
Acked-by: Viresh Kumar
@Kukjin: please take it through your tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
On 21 April 2015 at 18:47, Bartlomiej Zolnierkiewicz
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 tha
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
> ---
> drivers/cpufreq/exynos-cpufreq.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/exynos-cp
On 23-05-15, 08:32, Shailendra Verma wrote:
> During probe free the memory allocated to "exynos_info" in case of
> unknown SOC type.
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/cpufreq/exynos-cpufreq.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff -
> }
>
> @@ -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: Vires
"Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: linux...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Paul Gortmaker
> ---
>
> [ patch will be
ay, thanks.
> On Thu, Jun 18, 2015 at 1:54 PM, Viresh Kumar 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.
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
misse
ed 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
--
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 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.
flag in
> the frequency table entry.
>
> Cc: Tomasz Figa
> Cc: Michael Turquette
> Cc: Javier Martinez Canillas
> Cc: Thomas Abraham
> Cc: Viresh Kumar
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/cpufreq/cpufreq_opp.c | 2 ++
> 1 file chan
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.
>
On 27-07-15, 12:24, Bartlomiej Zolnierkiewicz wrote:
> Have you read my explanation of the issue?
>
> With your OPP-v2 patches cpufreq-dt picks turbo frequencies and uses
> them as normal ones.
>
> (More at: http://www.spinics.net/lists/arm-kernel/msg430397.html)
Yes I did. I understand that the
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 :)
> y
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 n
k-latency-ns = <20>;
> + };
> + opp11 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <20>;
> + };
> +
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.
>
>
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
> 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,
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
> >
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 thi
{ .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
> { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
> { /* sentinel */ }
> };
Otherwise looks fine:
Acked-by: Viresh Kumar
--
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
Oh, you are still alive? I thought you were about to get married :)
Just kidding !!
On 20 November 2014 00:58, Sudeep Holla 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 bette
On 24 November 2014 at 19:14, Sudeep Holla 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 upd
q_get_current_driver() || !cpufreq_frequency_get_table(0))
> {
Only !cpufreq_frequency_get_table(0) is enough here.
For rest:
Acked-by: Viresh Kumar
--
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 27 November 2014 at 19:38, Eduardo Valentin wrote:
>> Acked-by: Viresh Kumar
>
> Ok.
>
> though.. "normal practice" says ack's are oftern used by the maintainer
> of the affected code (quoting Documentation/SubmittingPatches) :-)
Hehe :)
Another par
On 27 November 2014 at 19:42, Eduardo Valentin wrote:
> (I'm sorry VireshK, I am still using my normal practice) :-)
That's fine :)
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 1ab0018..bed3fa2 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/t
On 28 November 2014 at 18:44, Eduardo Valentin 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 behav
On 28 November 2014 at 20:23, Eduardo Valentin 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 dev
-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi
Cc: Rob Herring
Cc: Zhang Rui
Acked-by: Viresh Kumar
Signed-off-by: Viresh Kumar
Signed-off-by: Eduardo Valentin
---
drivers/thermal/cpu_cooling.c | 5 +
drivers/thermal/db8500_cpufreq_cooling.c | 5
On 9 January 2015 at 02:48, Rob Herring 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
On 20 January 2015 at 13:53, Chanwoo Choi 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
On 20 January 2015 at 17:07, Chanwoo Choi 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
voltag
On 21 January 2015 at 09:50, Chanwoo Choi 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
On 21 January 2015 at 11:42, Chanwoo Choi wrote:
> OK, I understand.
> I'll try to update exynos memory bus according to your comment.
Great.
@Rob: So there is nothing special required for devfreq drivers in new
OPP bindings, right ? :)
--
To unsubscribe from this list: send the line "unsubscrib
On 21 January 2015 at 14:03, Lukasz Majewski 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),
On 21 January 2015 at 15:17, Lukasz Majewski 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 kno
On 23 January 2015 at 17:44, Lukasz Majewski 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 23 January 2015 at 19:27, Lukasz Majewski wrote:
> Please pay a note about following problem:
>
> Previously we got: cpu0: cpu@0 for all Exynos devices.
>
> Now, however, cpu numbering has changed (due to GIC rework).
> For example:
>
> Exynos4412:
> cpus {
> cpu0: cpu@A
HW: Exynos 4412 - Odroid U3.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Lukasz Majewski
> ---
> drivers/cpufreq/exynos-cpufreq.c | 21 ++---
> 1 file changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/driver
_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
> *
1ca87d 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq.c
> @@ -454,7 +454,7 @@ static struct cpufreq_driver s3c24xx_driver = {
> };
>
>
> -int __init s3c_cpufreq_register(struct s3c_cpufreq_info *info)
> +int s3c_cpufreq_register(s
On 29 January 2015 at 01:31, Arnd Bergmann 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 d
On 29 January 2015 at 15:31, Arnd Bergmann 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 deal
atforms
> 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
> Cc
1 - 100 of 254 matches
Mail list logo
