public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: cpufreq@vger.kernel.org, LKLM <linux-kernel@vger.kernel.org>,
	Rafal Bilski <rafalbilski@interia.pl>
Subject: Re: [PATCH] longhaul: select Longhaul version 2 for capable CPUs
Date: Sat, 24 Oct 2009 23:28:14 -0400	[thread overview]
Message-ID: <20091025032813.GB2475@redhat.com> (raw)
In-Reply-To: <20091024172538.e2c8776b.krzysztof.h1@poczta.fm>

On Sat, Oct 24, 2009 at 05:25:38PM +0200, Krzysztof Helt wrote:
 > From: Krzysztof Helt <krzysztof.h1@wp.pl>
 > 
 > There is a typo in the longhaul detection code so only Longhaul v1 or Longhaul v3
 > is selected. The Longhaul v2 is not selected even for CPUs which are capable of.
 > 
 > Tested on PCChips Giga Pro board. Frequency changes work and the Longhaul v2
 > detects that the board is not capable of changing CPU voltage.
 > 
 > Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
 
It seems we deliberately changed this two years ago, though the changelog
is a bit sparse on details..

commit 07844252ffd81ec192a62014bada1016c9703765
Author: Rafal Bilski <rafalbilski@interia.pl>
Date:   Sun Apr 22 12:26:04 2007 +0200

    [CPUFREQ] Longhaul - Revert Longhaul ver. 2
    
    There is something wrong with this code. It needs more
    testing. It is better to disable it for now because support
    for some machines will be broken.
    
    Signed-off-by: Rafal Bilski <rafalbilski@interia.pl>
    Signed-off-by: Dave Jones <davej@redhat.com>


In hindsight, changing it to report V1 instead of V2 was the wrong thing
to do, and we should have done something like -ENODEV with
a printk explaining why.

I've not got any old VIA CPUs/boards to test with any more, but I'm inclined
to apply your change, but we'll have to keep an eye out for any strange
bugs on affected systems.  Currently this driver should do nothing, as the
longhaul v1 registers that don't exist on longhaul V2 CPUs. With this change,
we're going to be actually doing scaling again, which may introduce instability
on some machines, as iirc, we never did get this driver 100% stable due
to a lot of really crappy motherboards.

Perhaps we should printk a warning related to this.
(We should definitly mention it in the Kconfig too, which I thought we already had)

	Dave


  reply	other threads:[~2009-10-25  3:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-24 15:25 [PATCH] longhaul: select Longhaul version 2 for capable CPUs Krzysztof Helt
2009-10-25  3:28 ` Dave Jones [this message]
2009-10-25 17:55   ` Rafał Bilski
2009-10-25 18:45   ` [PATCH] powernow-k6: set transition latency value so ondemand governor can be used Krzysztof Helt
2009-10-26  6:41     ` Ingo Molnar
2009-10-31 10:03   ` Krzysztof Helt
2009-11-03 19:51   ` [PATCH] longhaul: select Longhaul version 2 for capable CPUs Krzysztof Helt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091025032813.GB2475@redhat.com \
    --to=davej@redhat.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=krzysztof.h1@poczta.fm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafalbilski@interia.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox