= CPUFREQ_SHARED_TYPE_ANY;
+ cpumask_setall(policy-related_cpus);
cpumask_setall(policy-cpus);
This is required for all SMP systems.
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body
On 28 January 2013 17:56, Rafael J. Wysocki r...@sisk.pl wrote:
So here's a deal: I'll drop cpufreq: Simplify cpufreq_add_dev() for now and
you'll generate a new patch that won't cause the WARN_ON() to trigger. OK?
:(
Or what about set all cpus from policy-cpus into related_cpus in our core
On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa t.f...@samsung.com wrote:
On Exynos SoCs all cores share the same frequency setting, so changing
frequency of one core will affect rest of cores.
This patch modifies the exynos-cpufreq driver to inform cpufreq core
about this behavior and broadcast
On 31 January 2013 20:15, Tomasz Figa t.f...@samsung.com wrote:
On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
+ policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
I couldn't understand the use of this change. Can you please explain ?
All cores on Exynos SoCs share
On 31 January 2013 20:34, Tomasz Figa t.f...@samsung.com wrote:
Well, the fact that it isn't used at the moment doesn't mean that it
shouldn't be set correctly. The field is present in the structure and has
a set of defined values - one of which should be selected. For example,
I can imagine
On 31 January 2013 21:37, Tomasz Figa t.f...@samsung.com wrote:
Hmm. Now as I think of it, there might be another confusing aspect:
Could you explain what sw coordination and any coordination mean?
I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus
masks.
Check this out:
On 31 January 2013 21:42, Viresh Kumar viresh.ku...@linaro.org wrote:
On 31 January 2013 21:37, Tomasz Figa t.f...@samsung.com wrote:
Hmm. Now as I think of it, there might be another confusing aspect:
Could you explain what sw coordination and any coordination mean?
I mean specifically
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. The nature of exynos5440
clock controller is different from previous exynos controllers so not using
the common exynos cpufreq framework. Also, the device tree
On Thu, Feb 7, 2013 at 10:39 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
+#define DRIVER_NAMEexynos5440_dvfs
+static struct cpufreq_driver exynos_driver = {
+ .name = DRIVER_NAME,
+};
+
Since this driver is only for exynos5440, having the same names as
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This change is needed for adding different type of cpufreq driver
and support single binary image.
That's not sufficient, we need more description of the problem you faced.
--
To unsubscribe from this list: send
, it makes it more
readable. :)
On Thu, Feb 7, 2013 at 3:17 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- cpufreq_tbl: Table of frequencies
On 8 February 2013 08:56, amit kachhap amit.kach...@gmail.com wrote:
+ dvfs_info-dvfs_init = true;
why do you need this ?
This is added to synchronize the interrupts.
How? You are setting it once in init() and not touching it afterwards. :)
Yes but during init also if interrupts
On 2 March 2013 15:04, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they run at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
On 6 March 2013 13:35, amit kachhap amit.kach...@gmail.com wrote:
On Tue, Mar 5, 2013 at 6:48 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
+static void exynos_cpufreq_work(struct work_struct *work)
+{
+ unsigned int cur_pstate, index;
+ struct cpufreq_policy *policy
On 7 March 2013 12:13, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
+struct exynos_dvfs_data {
+ void __iomem *base;
+ struct resource *mem;
+ int irq;
+ struct clk
This is what Russell told me a long time back:
Don't use Adding, Fixing, etc words as this work is not something, which is
already done.
So your subject should have been: cpufreq: exynos: Add cpufreq driver
for exynos5440
Fix it if you need another version, which i believe you do :)
On Tue, Mar
On 19 March 2013 15:29, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
arch/arm/Kconfig
On 28 March 2013 13:35, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
Submitting the V5 version of exynos5440 cpufreq driver. This patchset
addresses
all the coding and design concerns raised especially by Viresh.
Changes in V5:
* Removed the unnecessary DT look up entry from
On 28 March 2013 13:35, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common
On 28 March 2013 13:35, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
+static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+ policy-cur = dvfs_info-cur_frequency;
+
On 25 March 2013 15:41, Viresh Kumar viresh.ku...@linaro.org wrote:
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Viresh
On 1 April 2013 14:13, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), found that the FIMD clocks
s/found/we found/
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are
On 31 March 2013 09:23, Viresh Kumar viresh.ku...@linaro.org wrote:
On 25 March 2013 15:41, Viresh Kumar viresh.ku...@linaro.org wrote:
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
On 5 April 2013 12:18, Kukjin Kim kgene@samsung.com wrote:
Basically, this moving looks good to me, but should be re-worked based on
for-next of samsung tree because this touches too many samsung stuff so this
should be sent to upstream via samsung tree.
Hmm... Its already applied in
On 5 April 2013 12:36, Viresh Kumar viresh.ku...@linaro.org wrote:
On 5 April 2013 12:18, Kukjin Kim kgene@samsung.com wrote:
Basically, this moving looks good to me, but should be re-worked based on
for-next of samsung tree because this touches too many samsung stuff so this
should
On 8 April 2013 13:47, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
On 8 April 2013 14:17, Viresh Kumar viresh.ku...@linaro.org wrote:
On 8 April 2013 13:47, Amit Daniel Kachhap amit.dan...@samsung.com wrote:
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index f3f3b14..bce2195 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers
On 8 April 2013 14:45, Kukjin Kim kgene@samsung.com wrote:
Rafael J. Wysocki wrote:
Well, I'm dropping it. Please merge via the Samsung tree.
OK, I will.
I got patch file from Viresh, and there is a sign from Rafael, but it should
be ack. So Rafael, let me use your ack on this patch
/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
With the resent of 1/4,
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
by Viresh Kumar viresh.ku...@linaro.org
Changes since v2:
- moved clk_prepare_enable() and clk_disable_unprepare() from
fimd_probe() to fimd_clock() as suggested by Inki Dae
inki@samsung.com
Changes since v1:
- added error checking for clk_prepare_enable
On 21 April 2013 20:13, Tomasz Figa tomasz.f...@gmail.com wrote:
3) after those two changes, all that remains is to fix compliance with
Common Clock Framework, in other words:
s/clk_enable/clk_prepare_enable/
and
s/clk_disable/clk_disable_unprepare/
We don't have to call
On 22 April 2013 15:26, Tomasz Figa t.f...@samsung.com wrote:
Can you assure that in future SoCs, on which this driver will be used, this
assumption will still hold true or even that in current Exynos driver this
behavior won't be changed?
Probably yes.. Registers for enabling/disabling these
on CPU_S5PV210
+ select CPU_FREQ_TABLE
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 23 April 2013 20:55, Kukjin Kim kgene@samsung.com wrote:
On 04/05/13 20:36, Rafael J. Wysocki wrote:
On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote:
On 5 April 2013 12:18, Kukjin Kimkgene@samsung.com wrote:
Basically, this moving looks good to me, but should be re
On 13 May 2013 16:21, Rafael J. Wysocki r...@sisk.pl wrote:
That doesn't matter I suppose. I can take it, but please rebase it on top
of current linux-next.
I have already done that (attached). But i wasn't sure what Kukjin wants as
he may report conflicts again and i will ask the same
On 29 April 2014 11:44, Amit Kachhap amit.kach...@gmail.com wrote:
In the frequency table dts file, the frequencies are arranged in
descending order which maps 1 to 1 with other frequency parameter to
be calculated and programmed in some registers.
But the OPP library works by generating the
On 2 May 2014 06:36, Nishanth Menon n...@ti.com wrote:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..281ccfb 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -17,6 +17,11 @@ config CPU_FREQ
if CPU_FREQ
+config CPU_FREQ_PM_OPP
+
On 2 May 2014 10:48, Nishanth Menon n...@ti.com wrote:
On Thu, May 1, 2014 at 11:30 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
new file mode 100644
index 000..2602ff8
--- /dev/null
+++ b/drivers/cpufreq
On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table)
{
- struct device_opp *dev_opp;
as needed isolated to just CPUFreq framework
alone.
Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: cpuf
On 5 May 2014 19:55, Nishanth Menon n...@ti.com wrote:
On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
What if opp is being added for some reason at the same time?
I hope we can surely see some awkward results, maybe some
NULL pointers invocations as well..
we
On 14 May 2014 06:32, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Access to samsung clock lock is required to support newer samsung specific
clock types. So change the scope of the samsung clock lock to global. And
Maybe bit more detail on why exactly
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over
to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos
specific cpufreq drivers for these platforms
On 14 May 2014 11:47, Lukasz Majewski l.majew...@samsung.com wrote:
I think that you can rely solely on the CPU_FREQ_BOOST_SW flag if the
original author of cpufreq-cpu0.c don't mind.
We don't have to. struct cpufreq_driver: boost_supported is always available.
Just update it without any ugly
On 14 May 2014 11:39, Lukasz Majewski l.majew...@samsung.com wrote:
I agree with Nishanth here, that point 1 (as described by Viresh at
[*]) is a more scalable approach.
The only reason why I wanted all that to be done at OPP level was to
ensure if somebody else also needs it apart from
On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote:
Could we please come up with a way to probe this from DT in the cpufreq-cpu0
driver itself, so we don't have to add a device in every platform using it?
Its followed that way because DT Maintainers had strong objections
to creating
On 14 May 2014 18:21, Arnd Bergmann a...@arndb.de wrote:
Thanks a lot for your continued effort. Looks great overall, but I have one
comment about the general way the cpu0 cpufreq driver works, not specific
to the exynos implementation. See my reply to patch 4.
I hope you meant 7 here instead
On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote:
Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar:
On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote:
Could we please come up with a way to probe this from DT in the
cpufreq-cpu0 driver itself, so we don't have to add
On 14 May 2014 19:13, Thomas Abraham ta.oma...@gmail.com wrote:
Okay, so you are suggesting that Kconfig entry used to select
cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well.
I never said that... That should be enabled by your defconfig instead.
What I said was, don't put code
On 14 May 2014 19:16, Thomas Abraham ta.oma...@gmail.com wrote:
On Wed, May 14, 2014 at 9:10 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
Why is this present outside of above if {} ? as boost_freqs is guaranteed to
be NULL without that.
Just to reduce indentation by one tab. No technical
On 14 May 2014 19:48, Thomas Abraham ta.oma...@gmail.com wrote:
Okay, I get the point about #ifdef in cpufreq-cpu0. What about your
earlier comment about the new Kconfig entry (Get rid of this.. just
not required.)? The new Kconfig entry would be needed in that case.
The only place you used
On 16 May 2014 13:20, Jonghwan Choi jhbird.c...@samsung.com wrote:
Commit 7da83a80 (ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach)
Why do you have a line break here ?
which lands in samsung tree causes build breakage for cpufreq-exynos like
following:
Enter a blank line
And please use Rafael's email id from Maintainers..
On 16 May 2014 13:25, Viresh Kumar viresh.ku...@linaro.org wrote:
On 16 May 2014 13:20, Jonghwan Choi jhbird.c...@samsung.com wrote:
Commit 7da83a80 (ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach)
Why do you have a line
On 16 May 2014 15:48, Jonghwan Choi jhbird.c...@samsung.com wrote:
Commit 7da83a80 (ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach) which lands in samsung tree causes build breakage
for cpufreq-exynos like following:
drivers/cpufreq/exynos-cpufreq.c: In function
On 21 May 2014 16:47, Tomasz Figa t.f...@samsung.com wrote:
Mostly nitpicks ..
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
- depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) !ARCH_MULTIPLATFORM
+
+++-
drivers/cpufreq/exynos4x12-cpufreq.c | 40 -
drivers/cpufreq/exynos5250-cpufreq.c | 43
+---
6 files changed, 119 insertions(+), 41 deletions(-)
Looks fine..
Acked-by: Viresh Kumar viresh.ku...@linaro.org
On 26 May 2014 03:11, Kukjin Kim kgene@samsung.com wrote:
I'm not sure Thomas' v5 cpufreq-cpu0 driver can be upstreamed for 3.16
because of dependency with others, some of them got ack though...
* PM / OPP: move cpufreq specific helpers out of OPP layer
-
On 23 May 2014 19:07, Thomas Abraham thomas...@samsung.com wrote:
From: Thomas Abraham thomas...@samsung.com
Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and
= cpu;
+ compatible = arm,cortex-a9;
+ reg = 1;
+ };
+ };
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
On 23 May 2014 19:57, Thomas Abraham thomas...@samsung.com wrote:
From: Thomas Abraham thomas...@samsung.com
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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
100644 drivers/cpufreq/exynos-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos-cpufreq.h
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
Acked-by: Viresh Kumar
Hi Guys,
I didn't had time to put in an effort on this but here is a problem
reported by Santosh. See if somebody can get this fixed..
arch/arm/mach-exynos/sleep.S: Assembler messages:
arch/arm/mach-exynos/sleep.S:57: Error: invalid immediate for address
calculation (value = 0x0004)
Its
-omap2/Kconfig| 1 -
arch/arm/mach-shmobile/Kconfig | 2 --
arch/arm/mach-vexpress/Kconfig | 1 -
arch/arm/mach-zynq/Kconfig | 1 -
drivers/devfreq/Kconfig| 1 -
kernel/power/Kconfig | 3 ---
10 files changed, 15 deletions(-)
Reviewed-by: Viresh Kumar viresh.ku
cpuf...@vger.kernel.org is dead now. Anyway you should be using linux-pm
instead.
On 13 June 2014 11:38, Chanwoo Choi cw00.c...@samsung.com wrote:
This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this
patchset is based on following patchset[1] by Thomas Abraham.
[1]
driver for these platforms. This
series also enabled cpufreq support for Exynos5420 using arm_big_little
cpufreq
driver.
cpuf...@vger.kernel.org list is deprecated now: dec102a, use linux-pm instead.
For patch 5 and 6:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from
,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_APPL_GPIO, NO_IRQ},
+ .irq = {IRQ_APPL_GPIO},
}
};
Acked-by: Viresh Kumar viresh.ku...@st.com
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
},
-};
+AMBA_APB_DEVICE(spear3xx_uart, uart, 0, SPEAR3XX_ICM1_UART_BASE,
+ {SPEAR3XX_IRQ_UART}, NULL);
/* Do spear3xx familiy common initialization part here */
void __init spear3xx_init(void)
Acked-by: Viresh Kumar viresh.ku...@st.com
--
viresh
--
To unsubscribe from this list: send
On 3/27/2012 9:49 PM, Arnd Bergmann wrote:
These bindings came up in a discussion IRC today. I think it's rather bad that
we can't agree on a common way to name the properties for mmc. We have
bindings being proposed or already included from Anton, Stephen, Shawn,
Rajendra, Viresh, Lee and
On Tue, Jun 18, 2013 at 11:59 AM, Chander Kashyap
chander.kash...@linaro.org wrote:
Instead of having to specify the number for CPUs in Exynos5250 in platsmp.c
file, let the number of CPUs be determined by having this information listed
in Exynos5250 device tree file.
Signed-off-by: Chander
On 2 September 2013 12:07, Chander Kashyap chander.kash...@linaro.org wrote:
I tested on 3.11-rc7.
Both the cpu's are booting. I didnet see any issue.
Strange.. I am sure about the problem I reported.. Please share your .config
and I will give it a try..
--
To unsubscribe from this list: send
On 2 September 2013 12:07, Chander Kashyap chander.kash...@linaro.org wrote:
I tested on 3.11-rc7.
Both the cpu's are booting. I didnet see any issue.
Oops!! I copied dtb to wrong location.. stupid mistake.. sorry.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
(*new_opp),+} GFP_KERNEL);
It is almost impossible to catch these with naked eyes for such long
patches.. I took help of --word-diff though :)
If no one else sees these as problems then feel free to add my:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send
On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote:
I am open to suggestions if any one feels we can improve this better.
I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp**
though..
I believe that change was from Patch #2[1]
Yeah.. I just replied on a single
On 19 November 2013 18:59, Jonghwan Choi jhbird.c...@gmail.com wrote:
Frequency lock should be considered in suspend/hibernation.
These could turn out to be important logs for future. Please write
with more effort..
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
-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
now.
Reported-by: Lan Tianyu tianyu@intel.com
Reported-by: Nishanth Menon n...@ti.com
Reported-by: Jinhyuk Choi jinc...@broadcom.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/base/power/main.c | 5 +
drivers/cpufreq/cpufreq.c | 50
Multiple platforms need to set CPU to a particular frequency before suspending
system. And so they need a common infrastructure which is provided by this
patch. Those platforms just need to initialize their -suspend() pointers with
the generic routine.
Signed-off-by: Viresh Kumar viresh.ku
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/tegra-cpufreq.c | 54
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 97
-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 98 +--
1 file changed, 18 insertions(+), 80 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b6c7821..026efe4a 100644
--- a/drivers/cpufreq
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/s5pv210-cpufreq.c | 49
.
@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you confirm
that.
Viresh Kumar (6):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: call driver's suspend/resume for each policy
cpufreq
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
@@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
might_sleep();
+ cpufreq_suspend();
+
mutex_lock(dpm_list_mtx);
pm_transition = state;
async_error = 0;
Shouldn't it do
On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index dc196bb..6d93f91 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -255,6 +255,9 @@ struct cpufreq_driver {
int cpufreq_register_driver(struct
On 25 November 2013 19:41, Viresh Kumar viresh.ku...@linaro.org wrote:
Currently we have implemented PM notifiers to disable/enable -target()
routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku
On 27 November 2013 07:12, Rafael J. Wysocki r...@rjwysocki.net wrote:
Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
since you've decided to put those things somewhere else thus making the
On 27 November 2013 01:53, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
This appears to be racy. Is it really racy, or just seemingly?
Why does it look racy
-and-tested-by: Nishanth Menon n...@ti.com
Reported-by: Jinhyuk Choi jinc...@broadcom.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
This is almost same as 1/6 of V3 version of this patchset:
https://lkml.org/lkml/2013/11/25/838
This is done to get some initial fixes for 3.13
On 28 November 2013 19:53, Rafael J. Wysocki r...@rjwysocki.net wrote:
I don't think that the Nishanth's issue is fixed by this particular version of
the patch, so I modified the changelog and removed a the comment above
cpufreq_suspend()
No, it does fix his issue as we are just stopping the
On 29 November 2013 01:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
So I'm reading this as the version of the patch in bleeding-edge is OK.
I hope that really is the case. :-)
Yeah, that's correct.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of
5a87182aa21d6d5d306840feab9321818dd3e2a3
Author: Viresh Kumar viresh.ku...@linaro.org
Date: Wed Nov 27 09:09:42 2013 +0530
cpufreq: suspend governors on system suspend/hibernate
This is already tested by few people and so incorporating their Tested-by as
well.
For: v3.14.
Viresh Kumar (6):
cpufreq: suspend
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/s5pv210-cpufreq.c | 49
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 25 +
include/linux/cpufreq.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 443c053..ae4923e 100644
--- a/drivers
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Acked-and-tested-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers
Currently we have implemented PM notifiers to disable/enable -target() routines
functionality during suspend/resume.
Now we have support present in cpufreq core, lets use it.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 96
1 - 100 of 236 matches
Mail list logo
