Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On Thu, Sep 4, 2014 at 7:00 PM, Kevin Hilman khil...@kernel.org wrote:
Thomas Abraham ta.oma...@gmail.com writes:
On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman khil...@kernel.org wrote:
Hi Thomas,
Thomas Abraham ta.oma...@gmail.com writes:
[...]
A new branch [1] has been created using commits from exynos5-v3.17-rc1
branch + cpufreq + regulator + temp fixes. I have tested this branch
on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand
and performance governors. Please let me know if there are any issues
with this new branch. It is based on v3.17-rc3.
Excellent! Thank you.
The only thing missing now is the CPUidle support for 5800, and all
that's needed for that is the compatible string patch[1] which Daniel
has queued up.
With that patch, display + CPUidle + CPUfreq are working pretty well on
my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I
turn on the switcher, it boots OK, but as soon as I try to run powertop
(upstream v2.6.1) it gets stuck. Have you tried this branch with the
switcher enabled?
Yes, I have tested switcher + cpufreq + cpuidle with this branch and
there are no issues found. I haven't tested with powertop yet. I will
try and do that and let you know the result.
You mentioned that when you run powertop, it gets stuck. When that
happens, is there any log on the console or does system just turn
unresponsive?
The console is not responsive, but kernel seems busy because I see
periodic timeout messages from the samsung clock driver.
Ok, I haven't tried to recreate this issue. I will try and do that.
Note that I see these messages when things are functioning normally
also.
I did notice this a few times before but today I was able to reproduce
this consistently with other test cases. This timeout is because the
CPU clock blocks of the cluster that has been turned down are being
reconfigured, which on Exynos will not work. The following is a
temporary patch which solves this issue.
From b0c4057d428134fe12446431ede1d9a579fd1d05 Mon Sep 17 00:00:00 2001
From: Thomas Abraham thomas...@samsung.com
Date: Fri, 5 Sep 2014 17:11:10 +0530
Subject: [PATCH] TEMP: cpufreq/bL: let the CPU switch complete before
scaling frequency
On Exynos5420/Exyons5800, the clock blocks that make up the CPU clock
supply do no operate when the cluster in which they belong is powered off.
The CPU clock supply path is PLL - Mux/Dividers - CPU_clock.
In the arm_big_little CPUfreq driver, the frequency is scaled first and
then the CPU is switched to the new cluster. In case the switch was for
the first-man CPU in that new cluster, the frequency scaling step in
arm_big_little CPUfreq driver would not work for Exynos since the
in-bound cluster is powered off at that point. Note: On Exynos, the
cluster is powered off when all the CPUs in that cluster are powered off
which implies that the CPU clock blocks for that cluster do not operate
anymore.
So when using arm_big_little CPUfreq driver for Exynos, two changes are
required. The first change is to let the CPU to switch to the new cluster
before scaling the frequency. The second change is to ensure that the
switch has been completed before scaling the frequency.
With these changes, the message wait_until_divider_stable: timeout in
divider stabilization is not seen anymore.
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/include/asm/bL_switcher.h | 15 ++-
drivers/cpufreq/arm_big_little.c |9 -
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/bL_switcher.h
b/arch/arm/include/asm/bL_switcher.h
index 1714800..d609b86 100644
--- a/arch/arm/include/asm/bL_switcher.h
+++ b/arch/arm/include/asm/bL_switcher.h
@@ -20,9 +20,22 @@ typedef void (*bL_switch_completion_handler)(void *cookie);
int bL_switch_request_cb(unsigned int cpu, unsigned int new_cluster_id,
bL_switch_completion_handler completer,
void *completer_cookie);
+
+static void bL_switch_complete_cb(void *cookie)
+{
+struct completion *switch_complete = (struct completion *) cookie;
+complete(switch_complete);
+}
+
static inline int bL_switch_request(unsigned int cpu, unsigned int
new_cluster_id)
{
- return bL_switch_request_cb(cpu, new_cluster_id, NULL, NULL);
+ struct completion complete;
+
+ init_completion(complete);
+ bL_switch_request_cb(cpu, new_cluster_id, bL_switch_complete_cb,
+ complete);
+ wait_for_completion(complete);
+ return 0;
}
/*
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index a46c223..baeff47 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -129,6 +129,13 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32
new_cluster, u32 rate)
int ret;
bool bLs = is_bL_switching_enabled();
+ /* Switch cluster */
+
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, Thomas Abraham ta.oma...@gmail.com writes: [...] A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3. Excellent! Thank you. The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up. With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled? Yes, I have tested switcher + cpufreq + cpuidle with this branch and there are no issues found. I haven't tested with powertop yet. I will try and do that and let you know the result. You mentioned that when you run powertop, it gets stuck. When that happens, is there any log on the console or does system just turn unresponsive? Thanks, Thomas. Thanks again for your work on this, we're getting close! Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279028.html -- 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
Thomas Abraham ta.oma...@gmail.com writes: On Thu, Sep 4, 2014 at 4:45 AM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, Thomas Abraham ta.oma...@gmail.com writes: [...] A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3. Excellent! Thank you. The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up. With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled? Yes, I have tested switcher + cpufreq + cpuidle with this branch and there are no issues found. I haven't tested with powertop yet. I will try and do that and let you know the result. You mentioned that when you run powertop, it gets stuck. When that happens, is there any log on the console or does system just turn unresponsive? The console is not responsive, but kernel seems busy because I see periodic timeout messages from the samsung clock driver. Note that I see these messages when things are functioning normally also. Kevin [1] [ 337.832031] wait_until_divider_stable: timeout in divider stablization [ 337.847024] wait_until_divider_stable: timeout in divider stablization [ 337.862024] wait_until_divider_stable: timeout in divider stablization [ 337.957028] wait_until_divider_stable: timeout in divider stablization [ 337.972024] wait_until_divider_stable: timeout in divider stablization [ 337.987024] wait_until_divider_stable: timeout in divider stablization [ 340.082029] wait_until_divider_stable: timeout in divider stablization [ 340.097024] wait_until_divider_stable: timeout in divider stablization [ 340.112024] wait_until_divider_stable: timeout in divider stablization [ 346.242030] wait_until_divider_stable: timeout in divider stablization [ 346.257024] wait_until_divider_stable: timeout in divider stablization [ 346.272024] wait_until_divider_stable: timeout in divider stablization [ 348.322029] wait_until_divider_stable: timeout in divider stablization [ 348.337025] wait_until_divider_stable: timeout in divider stablization [ 348.352024] wait_until_divider_stable: timeout in divider stablization -- 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 Wed, Sep 3, 2014 at 9:56 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman khil...@kernel.org wrote: HI Thomas, Thomas Abraham ta.oma...@gmail.com writes: On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary. That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier. I also noticed that the force vdd_arm and vdd_kfc to max voltage patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. This also is a temporary patch and by max voltage I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch. Are there any plans to update the main
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Thomas, Thomas Abraham ta.oma...@gmail.com writes: [...] A new branch [1] has been created using commits from exynos5-v3.17-rc1 branch + cpufreq + regulator + temp fixes. I have tested this branch on Exynos5800 Chromebook2 and cpufreq works fine with both ondemand and performance governors. Please let me know if there are any issues with this new branch. It is based on v3.17-rc3. Excellent! Thank you. The only thing missing now is the CPUidle support for 5800, and all that's needed for that is the compatible string patch[1] which Daniel has queued up. With that patch, display + CPUidle + CPUfreq are working pretty well on my exynos5800/chromebook2 with the big.LITTLE switcher disabled. If I turn on the switcher, it boots OK, but as soon as I try to run powertop (upstream v2.6.1) it gets stuck. Have you tried this branch with the switcher enabled? Thanks again for your work on this, we're getting close! Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279028.html -- 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
HI Thomas, Thomas Abraham ta.oma...@gmail.com writes: On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. I also noticed that the force vdd_arm and vdd_kfc to max voltage patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) Are there any plans to update the main referece branch and include cpufreq? Kevin [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a -- 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
Hi Kevin, On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman khil...@kernel.org wrote: HI Thomas, Thomas Abraham ta.oma...@gmail.com writes: On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary. That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier. I also noticed that the force vdd_arm and vdd_kfc to max voltage patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. This also is a temporary patch and by max voltage I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch. Are there any plans to update the main referece branch and include cpufreq? Yes, a new branch with all the latest patches (cpufreq +
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Thanks, Thomas. Thanks for looking into this, Kevin -- 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
Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Sorry for the delaying in following up. Thanks, Thomas. Kevin [1]https://github.com/exynos-reference/kernel.git -- 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 -- 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
Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. Thanks for looking into this, Kevin -- 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 Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: Hi Kevin, On Mon, Aug 25, 2014 at 9:02 PM, Kevin Hilman khil...@linaro.org wrote: Hi Chander, Chander Kashyap k.chan...@samsung.com writes: [...] I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled). As of now voltage scaling support is not there in generic big-little cpufreq driver (arm_big_little.c). Hence need to tie arm and kfc voltages to highest level for testing. Without this change stability issues are there, but with this change everything is stable. Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. Are there other out of tree dependencies that I'm missing? Is the max77802 regulator support that's in mainline sufficient? or am I missing some stuff there? Kevin -- 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 Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? Kevin [1]https://github.com/exynos-reference/kernel.git -- 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
Hi Tomasz, Hi Kevin, Thanks for taking a look at this. On 23.08.2014 01:54, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next. No, it has not. In general it was already too late in the release cycle when the last version was posted. I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it... Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs. I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs. It is a huge step forward - to be honest it is a serious rework of cpufreq subsystem for Exynos SoCs. Also I'd like to hear some confirmation from Samsung Poland RD Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2). Since we have missed the merge window with this code, I can declare that I will provide code, which means that I will do the cleanup for excluded from this series Exynos4 SoCs, to test the cpufreq-cpu0. However, I'm concerned with Exynos4412, which supports BOOST. It might not be trivial to provide support for it. I think, that we shall not drop behind any functionality during clean up. Also, the patch below[2] is needed for 5800. FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing. The patch looks fine to me (well, it's trivial :)), thanks. Best regards, Tomasz ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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
Hey, On Fri, 2014-08-22 at 16:54 -0700, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next. Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs. I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. Also, the patch below[2] is needed for 5800. For reference, I had the same patch in a kernel tree we recently used for a demo on the chromebook 2 13 (Exynos 5800). We didn't see any stability issues due to this without CPUidle (using the ondemand govenor). The kernel we ended up using had CONFIG_BL_SWITCHER disabled, but i don't remember seeing stability issues when i did a testrun with that enabled. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, Tomasz, On Sat, Aug 23, 2014 at 5:32 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Kevin, Thanks for taking a look at this. On 23.08.2014 01:54, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next. No, it has not. In general it was already too late in the release cycle when the last version was posted. I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it... Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs. I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled). As of now voltage scaling support is not there in generic big-little cpufreq driver (arm_big_little.c). Hence need to tie arm and kfc voltages to highest level for testing. Without this change stability issues are there, but with this change everything is stable. I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs. Also I'd like to hear some confirmation from Samsung Poland RD Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2). Also, the patch below[2] is needed for 5800. FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing. The patch looks fine to me (well, it's trivial :)), thanks. Best regards, Tomasz ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel regards, Chander -- 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
Hi Chander, Chander Kashyap k.chan...@samsung.com writes: [...] I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled). As of now voltage scaling support is not there in generic big-little cpufreq driver (arm_big_little.c). Hence need to tie arm and kfc voltages to highest level for testing. Without this change stability issues are there, but with this change everything is stable. Can you clarify how you're setting the voltages to ensure stability? Tomasz, I didn't mean to suggest this isn't ready for mainline. For the 5420/5800 it seems cpufreq support is a new feature, so this isn't a regression against previous (mainline) behavior. Maybe the big.LITTLE cpufreq support should've been separated out from the cleanup since it's more of a new feature, but that's up to you. Kevin -- 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.08.2014 17:32, Kevin Hilman wrote: Hi Chander, Chander Kashyap k.chan...@samsung.com writes: [...] I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I have tested this patch series on SMDK5420 with cpuidle (with and without b.L switcher enabled). As of now voltage scaling support is not there in generic big-little cpufreq driver (arm_big_little.c). Hence need to tie arm and kfc voltages to highest level for testing. Without this change stability issues are there, but with this change everything is stable. Can you clarify how you're setting the voltages to ensure stability? Tomasz, I didn't mean to suggest this isn't ready for mainline. I haven't said that either. I'd just like to know in what state this series is in case of those SoCs. However, if there are stability issues on them, there is also a chance that the same is true for other boards. Anyway, we're early in releasy cycle, so probably we could get better test coverage with this series in linux-next. Kukjin, Viresh, how would you want to proceed with merging it? It touches mach-exynos, cpufreq and samsung-clk, so it is non-trivial to merge. However as far as I can see the cpufreq-related changes are just a number of full file deletes and minor Makefile/Kconfig updates. It will be more difficult with mach-exynos changes, as they are more likely to produce conflict. The only solution that comes to my mind is that I first apply patches 1 and 2, create a stable branch for Kukjin, then he applies patches 3, 4, and 5 and creates a stable branch for me, on top of which I apply patch 6. Best regards, Tomasz -- 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin,
On Mon, Aug 25, 2014 at 9:02 PM, Kevin Hilman khil...@linaro.org wrote:
Hi Chander,
Chander Kashyap k.chan...@samsung.com writes:
[...]
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm
testing along with CPUidle, so there may be some untested interactions
there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq
together big.LITTLE 5420/5800, with or without the switcher.
I have tested this patch series on SMDK5420 with cpuidle (with and
without b.L switcher enabled).
As of now voltage scaling support is not there in generic big-little
cpufreq driver (arm_big_little.c).
Hence need to tie arm and kfc voltages to highest level for testing.
Without this change stability issues are there, but with this change
everything is stable.
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -225,7 +225,7 @@
buck2_reg: BUCK2 {
regulator-name = vdd_arm;
- regulator-min-microvolt = 80;
+ regulator-min-microvolt = 150;
regulator-max-microvolt = 150;
regulator-always-on;
regulator-boot-on;
@@ -260,7 +260,7 @@
buck6_reg: BUCK6 {
regulator-name = vdd_kfc;
- regulator-min-microvolt = 80;
+ regulator-min-microvolt = 150;
regulator-max-microvolt = 150;
regulator-always-on;
regulator-boot-on;
Tomasz, I didn't mean to suggest this isn't ready for mainline. For the
5420/5800 it seems cpufreq support is a new feature, so this isn't a
regression against previous (mainline) behavior. Maybe the big.LITTLE
cpufreq support should've been separated out from the cleanup since it's
more of a new feature, but that's up to you.
Kevin
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
regards,
Chander
--
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
Tomasz Figa tomasz.f...@gmail.com writes:
Kukjin,
On 31.07.2014 20:32, Kukjin Kim wrote:
On 07/30/14 17:07, Thomas Abraham wrote:
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figat.f...@samsung.com
Cc: Kukjin Kimkgene@samsung.com
Looks good to me,
Acked-by: Kukjin Kim kgene@samsung.com
BTW, who will handle this series? I hope see this series in 3.17.
This series consists mostly of clock changes and it likely depends on
patches already in my for-next, so I would be inclined toward taking it
through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your
samsung-clk tree, nor in Kukjin's for-next.
Also, I'm curious whether or how this is has been tested on big.LITTLE
SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm
testing along with CPUidle, so there may be some untested interactions
there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq
together big.LITTLE 5420/5800, with or without the switcher.
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the
exynos-reference tree where I've added the DT patch needed for CPUidle,
this series (and it's dependencies) which is what I'm using for testing.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git
wip/exynos/integ
[2]
From 72ee00246c0fbdcf5dbb0bf910b8a427da4ac002 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@linaro.org
Date: Fri, 22 Aug 2014 16:04:11 -0700
Subject: [PATCH] ARM: Exynos: use generic cpufreq driver for Exynos5800
As a derivative of the 5420, the 5800 SoC should use the generic
big.LITTLE driver for Exynos5800 as well.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
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 8923d37c3e85..debe50bf736a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -283,6 +283,7 @@ static void __init exynos_init_irq(void)
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = samsung,exynos5420, .data = arm-bL-cpufreq-dt },
+ { .compatible = samsung,exynos5800, .data = arm-bL-cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-cpu0 },
{ .compatible = samsung,exynos4210, .data = cpufreq-cpu0 },
{ .compatible = samsung,exynos5440, .data = exynos5440-cpufreq },
--
1.9.2
--
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
Hi Kevin, Thanks for taking a look at this. On 23.08.2014 01:54, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. So has this series been picked up anywhere? I don't see it in your samsung-clk tree, nor in Kukjin's for-next. No, it has not. In general it was already too late in the release cycle when the last version was posted. I had a plan to take it through clock tree with Kukjin's and Viresh's cooperation, but now as you say it... Also, I'm curious whether or how this is has been tested on big.LITTLE SoCs. I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm testing along with CPUidle, so there may be some untested interactions there as it seems a bit more stable without CPUidle enabled. I'd love to hear from anyone else that's testing CPUidle and CPUfreq together big.LITTLE 5420/5800, with or without the switcher. I'd definitely like to see a clarification on this issues, before this series hits mainline or at least its parts related to affected SoCs. Also I'd like to hear some confirmation from Samsung Poland RD Center guys (on CC), whether this code works stable on their target boards (Universal C210, Trats, Trats2). Also, the patch below[2] is needed for 5800. FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the exynos-reference tree where I've added the DT patch needed for CPUidle, this series (and it's dependencies) which is what I'm using for testing. The patch looks fine to me (well, it's trivial :)), thanks. Best regards, Tomasz -- 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
Hi Tomasz, On Fri, Aug 1, 2014 at 1:00 AM, Tomasz Figa tomasz.f...@gmail.com wrote: On 31.07.2014 21:25, Thomas Abraham wrote: On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa tomasz.f...@gmail.com wrote: On 31.07.2014 20:40, Tomasz Figa wrote: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree. [1] ARM: dts: add CPU nodes for Exynos4 SoCs - https://lkml.org/lkml/2014/7/21/315 [2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt - http://www.spinics.net/lists/arm-kernel/msg351134.html Aha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards. The v9 revision of this series has completed about 2 days of testing now on 4210/5250/5420 boards. I will let it run for few more days. For v8 and previous versions, the tests had completed 3 or more days. So I really don't think there is anything fundamentally wrong with this series. It would be nice to have this series merged and we start migrating other Exynos based boards to use generic cpufreq drivers. We have 22 Exynos-based boards currently supported in mainline. Is the testing running on all of them? This is the purpose of linux-next and This series replaces existing cpufreq driver for Exynos4210 and Exynos5250 which impact 7 Exynos boards - Exynos4210 (smdk, origen, trats, universal), Exynos5250 (smdk, arndale, snow). Out of these, it is trats and universal that have not been tested. Which other 15 Exynos boards did you feel this series needs to be tested on? Sanity testing for Exynos4x12 cpufreq support was done on Exynos4412 Origen board. for series that completely replace one driver with another I'd consider this as the only reasonable choice, if not keeping the old driver for a release. Of course we have never good testing traditions on Samsung SoC (see OMAP and Tegra baseline tests), but does it mean that we shouldn't start doing the right thing? Aren't Tegra/OMAP baseline tests for upstream kernel versions only, not for linux-next? Thanks, Thomas. Best regards, Tomasz -- 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 07/30/14 17:07, Thomas Abraham wrote:
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figat.f...@samsung.com
Cc: Kukjin Kimkgene@samsung.com
Looks good to me,
Acked-by: Kukjin Kim kgene@samsung.com
BTW, who will handle this series? I hope see this series in 3.17.
- Kukjin
Signed-off-by: Thomas Abrahamthomas...@samsung.com
Reviewed-by: Tomasz Figat.f...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 493dbc2..e61bb36 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -281,6 +281,28 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
}
+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,exynos5440, .data = exynos5440-cpufreq },
+ { /* sentinel */ }
+};
+
+static void __init exynos_cpufreq_init(void)
+{
+ struct device_node *root = of_find_node_by_path(/);
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos_cpufreq_matches, root);
+ if (!match) {
+ platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ return;
+ }
+
+ platform_device_register_simple(match-data, -1, NULL, 0);
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -320,7 +342,7 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible(samsung,exynos5250))
platform_device_register(exynos_cpuidle);
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ exynos_cpufreq_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree. [1] ARM: dts: add CPU nodes for Exynos4 SoCs - https://lkml.org/lkml/2014/7/21/315 [2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt - http://www.spinics.net/lists/arm-kernel/msg351134.html Best regards, Tomasz -- 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 31.07.2014 20:40, Tomasz Figa wrote: Kukjin, On 31.07.2014 20:32, Kukjin Kim wrote: On 07/30/14 17:07, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figat.f...@samsung.com Cc: Kukjin Kimkgene@samsung.com Looks good to me, Acked-by: Kukjin Kim kgene@samsung.com BTW, who will handle this series? I hope see this series in 3.17. This series consists mostly of clock changes and it likely depends on patches already in my for-next, so I would be inclined toward taking it through samsung-clk tree. However, for this I would need Acks for patch 5/6 from Viresh and for patches [1] and [2] (which are dependencies of this series) from you. I also need to make sure that the two mentioned patches don't have any dependencies already in your tree. [1] ARM: dts: add CPU nodes for Exynos4 SoCs - https://lkml.org/lkml/2014/7/21/315 [2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt - http://www.spinics.net/lists/arm-kernel/msg351134.html Aha, I'm not quite sure we really want to hurry with this series for 3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit in linux-next for a while an be thoroughly tested on a number of boards. This would also have the advantage of having the two patches mentioned above already merged. Best regards, Tomasz -- 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figa t.f...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 493dbc2..e61bb36 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -281,6 +281,28 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
}
+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,exynos5440, .data = exynos5440-cpufreq },
+ { /* sentinel */ }
+};
+
+static void __init exynos_cpufreq_init(void)
+{
+ struct device_node *root = of_find_node_by_path(/);
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos_cpufreq_matches, root);
+ if (!match) {
+ platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ return;
+ }
+
+ platform_device_register_simple(match-data, -1, NULL, 0);
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -320,7 +342,7 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible(samsung,exynos5250))
platform_device_register(exynos_cpuidle);
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ exynos_cpufreq_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.7.9.5
--
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
