headers
Rafal Bilski | 2 Apr 2012 22:41
Picon
Favicon

[PATCH] Longhaul: Check for CPU model first

This patch fixes bug 16274. This is C3 only driver, but APIC and
SMP checks are executed on any Centaur processor. Check for CPU
model first and stop produce bogus error messages on C7 and Nano
systems.

Signed-off-by: Rafal Bilski <rafalbilski <at> interia.pl>
---

Please close bug 16274 if this patch is accepted.

 drivers/cpufreq/longhaul.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index f47d26e..f70287e 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
 <at>  <at>  -959,22 +959,23  <at>  <at>  static int __init longhaul_init(void)
 	if (c->x86_vendor != X86_VENDOR_CENTAUR || c->x86 != 6)
 		return -ENODEV;

+	switch (c->x86_model) {
+	case 6 ... 9:
 #ifdef CONFIG_SMP
-	if (num_online_cpus() > 1) {
-		printk(KERN_ERR PFX "More than 1 CPU detected, "
-				"longhaul disabled.\n");
-		return -ENODEV;
-	}
+		if (num_online_cpus() > 1) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Apr 2012 17:49

[Bug 43037] New: cpufreq often stucks in lowest frequency.

https://bugzilla.kernel.org/show_bug.cgi?id=43037

           Summary: cpufreq often stucks in lowest frequency.
           Product: Power Management
           Version: 2.5
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: cpufreq
        AssignedTo: cpufreq <at> vger.kernel.org
        ReportedBy: yasar11732 <at> gmail.com
        Regression: No

Created an attachment (id=72798)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72798)
Current linux configuration file

Although it works from time to time, cpufreq often stucks in the lowest
frequency, and won't let the frequency go any higher, regardless of the
governer. There is a discussion about this in here:
https://bbs.archlinux.org/viewtopic.php?pid=1082045

As it can be seen on the above thread, when this occurs, cpufreq-info gives
this kind of output;

analyzing CPU 0:
  driver: acpi-cpufreq
(Continue reading)

Permalink | Reply | 7 comments |
headers
bugzilla-daemon | 3 Apr 2012 17:51

[Bug 43037] cpufreq often stucks in lowest frequency.

https://bugzilla.kernel.org/show_bug.cgi?id=43037

--- Comment #1 from Yaşar Arabacı <yasar11732 <at> gmail.com>  2012-04-03 15:51:07 ---
Created an attachment (id=72799)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72799)
Output of lspci -vv

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Apr 2012 18:07

[Bug 43037] cpufreq often stucks in lowest frequency.

https://bugzilla.kernel.org/show_bug.cgi?id=43037

--- Comment #2 from Yaşar Arabacı <yasar11732 <at> gmail.com>  2012-04-03 16:07:32 ---
Created an attachment (id=72800)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72800)
cat /proc/cpuinfo

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Linus Walleij | 4 Apr 2012 01:26
Favicon

Re: [PATCH v2] cpufreq: ondemand: handle SW coordinated CPUs

2012/3/9 Linus Walleij <linus.walleij <at> stericsson.com>:

> From: Rickard Andersson <rickard.andersson <at> stericsson.com>
>
> This patch fixes a bug that occured when we had load on
> a secondary CPU and the primary CPU was sleeping. Only
> one sampling timer was spawned and it was spawned as a
> deferred timer on the primary CPU, so when a secondary CPU
> had a change in load this was not detected by the ondemand
> governor.
>
> This patch make sure that deferred timers are run on all
> CPUs in the case of software controlled CPUs that run on
> the same frequency.
>
> Signed-off-by: Rickard Andersson <rickard.andersson <at> stericsson.com>
> Reviewed-by: Mian Yousaf Kaukab <mian.yousaf.kaukab <at> stericsson.com>
> Reviewed-by: Jonas Aberg <jonas.aberg <at> stericsson.com>
> Signed-off-by: Linus Walleij <linus.walleij <at> linaro.org>

Ping on this. This is a very real problem to us so we'd like to
get some feedback on this...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
MyungJoo Ham | 4 Apr 2012 12:23

[PATCH] EXYNOS: bugfix on retrieving old_index from freqs.old

The policy might have been changed since last call of target().
Thus, using cpufreq_frequency_table_target(), which depends on
policy to find the correspoding index from a frequency, may return
inconsistent index for freqs.old. Thus, old_index should be
calculated not based on the current policy.

We have been observing such issue when scaling_min/max_freq were
updated and sometimes caused system lockups due to incorrectly
configured voltages.

Signed-off-by: MyungJoo Ham <myungjoo.ham <at> samsung.com>
---
 drivers/cpufreq/exynos-cpufreq.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index b243a7e..1577522 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
 <at>  <at>  -62,8 +62,17  <at>  <at>  static int exynos_target(struct cpufreq_policy *policy,
 		goto out;
 	}

-	if (cpufreq_frequency_table_target(policy, freq_table,
-					   freqs.old, relation, &old_index)) {
+	/*
+	 * The policy may have been changed so that we cannot get proper
+	 * old_index with cpufreq_frequency_table_target(). Thus, ignore
+	 * policy and get the index from the raw frequency table.
+	 */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell King - ARM Linux | 4 Apr 2012 16:52
Picon

Re: Fix exposure of ARM_EXYNOS4210_CPUFREQ

On Wed, Mar 28, 2012 at 05:59:13PM -0700, Kukjin Kim wrote:
> Russell King wrote:
>> As predicted, this is breaking other ARM platforms.  Please fix this
>> yourself before your crappy code gets pushed into mainline.  Thanks.
>>
> I fixed it.

When will we see patches or the fix in mainline?
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 9 comments |
headers
'Dave Jones' | 4 Apr 2012 16:59
Picon
Favicon

Re: Fix exposure of ARM_EXYNOS4210_CPUFREQ

On Wed, Apr 04, 2012 at 03:52:04PM +0100, Russell King - ARM Linux wrote:
 > On Wed, Mar 28, 2012 at 05:59:13PM -0700, Kukjin Kim wrote:
 > > Russell King wrote:
 > >> As predicted, this is breaking other ARM platforms.  Please fix this
 > >> yourself before your crappy code gets pushed into mainline.  Thanks.
 > >>
 > > I fixed it.
 > 
 > When will we see patches or the fix in mainline?

Just send it to Linus directly.

	Dave
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 8 comments |
headers
Russell King - ARM Linux | 4 Apr 2012 17:03
Picon

Re: Fix exposure of ARM_EXYNOS4210_CPUFREQ

On Wed, Apr 04, 2012 at 10:59:17AM -0400, 'Dave Jones' wrote:
> On Wed, Apr 04, 2012 at 03:52:04PM +0100, Russell King - ARM Linux wrote:
>  > On Wed, Mar 28, 2012 at 05:59:13PM -0700, Kukjin Kim wrote:
>  > > Russell King wrote:
>  > >> As predicted, this is breaking other ARM platforms.  Please fix this
>  > >> yourself before your crappy code gets pushed into mainline.  Thanks.
>  > >>
>  > > I fixed it.
>  > 
>  > When will we see patches or the fix in mainline?
> 
> Just send it to Linus directly.

'it'... well, that implies that someone already has a patch.  I've asked
Kukjin to fix the problem which he introduced because exynos is getting
rather complicated, and he'll know what the dependencies should be.  So
far I've yet to see any kind of patch fixing this stuff.

Meanwhile I'm seeing failing randconfig builds for non-exynos ARM for
about a week due to the lack of dependencies.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Russell King - ARM Linux | 4 Apr 2012 17:07
Picon

Re: Fix exposure of ARM_EXYNOS4210_CPUFREQ

On Wed, Apr 04, 2012 at 04:03:53PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 04, 2012 at 10:59:17AM -0400, 'Dave Jones' wrote:
> > On Wed, Apr 04, 2012 at 03:52:04PM +0100, Russell King - ARM Linux wrote:
> >  > On Wed, Mar 28, 2012 at 05:59:13PM -0700, Kukjin Kim wrote:
> >  > > Russell King wrote:
> >  > >> As predicted, this is breaking other ARM platforms.  Please fix this
> >  > >> yourself before your crappy code gets pushed into mainline.  Thanks.
> >  > >>
> >  > > I fixed it.
> >  > 
> >  > When will we see patches or the fix in mainline?
> > 
> > Just send it to Linus directly.
> 
> 'it'... well, that implies that someone already has a patch.  I've asked
> Kukjin to fix the problem which he introduced because exynos is getting
> rather complicated, and he'll know what the dependencies should be.  So
> far I've yet to see any kind of patch fixing this stuff.
> 
> Meanwhile I'm seeing failing randconfig builds for non-exynos ARM for
> about a week due to the lack of dependencies.

Actually, given that this has been known about since Feb 13th, I'm now
going to ask for the exynos cpufreq updates to be reverted because
there's clearly no motivation to fix this crap Kconfig shite.  Having
it tossed out of mainline will provide the necessary motivation to get
people to fix their own fuckups.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 3 comments |

Gmane