From: Dave Jones <davej@redhat.com>
To: cpufreq@www.linux.org.uk
Subject: Re: post-OLS pending cpufreq patches
Date: Mon, 2 Aug 2004 20:33:50 +0100 [thread overview]
Message-ID: <20040802193350.GA15740@redhat.com> (raw)
In-Reply-To: <20040727205126.GB9438@dominikbrodowski.de>
On Tue, Jul 27, 2004 at 10:51:26PM +0200, Dominik Brodowski wrote:
> - [core] HT fix before CPU group support is merged
> fixes bug #3012: blind de-referencing of CPUdata independent of
> whether this CPU is actually registered with the CPUfreq core is
> bad. The small fix proposed is really straightforward, the proper
> solution will be to merge the cpufreq-SMT patchkit, but that's much
> more invasive and not yet completely ready. A "must" for 2.6.8.
couldnt find this in my inbox/cpufreq folder. can you bounce this please?
> - [speedstep-smi] get_frequencies SMM call causes failures
> fixes bug reported by Pierre Maziere. Also really straightforward.
ditto (unless this is the 0xffff patch I just merged ?)
> - [speedstep-centrino] reduce Jeremey's mail [Jeremey Fitzhardinge]
> latest version looks good, I'm just not yet 100% sure whether
> initialization of table is according to new/2.6. coding stlye.
> Please consider for merging for 2.6.8, too.
merged.
> - [speedstep-centrino] SMP support [Venkatesh Pallipadi]
> looks good, IMO, but needs to be adapted to Jeremey's patch which
> should go in first, IMO.
merged.
> - [pmac] scaling_availbale_frequencies, #define cleanup [John Clemens]
> x [pmac] does it keep frequency across suspend? If not, remove "equal" check
> in target and/or set_speed
> Don't really know about pmac's side of things, just wanted to
> mention it again.
pmac bits I'd rather go via benh, as he has a far better handle
on whats going on in that world, along with hardware with which
to test these changes.
> - [core] SMT patchkit
> needs a bit of work, will re-submit for 2.6.9
Hmm.
Subject: Re: [PATCH 2.6.8-rc2] speedstep SMT support
...
DB> Patch looks good, so: Dave, could you please merge it?
Merged.
> x [gx-suspmod] trouble
> gx-suspmod seems to be quite sick right now. Even reverting the
> latest changes leads to strange behaviour. Investigating...
> - [acpi-core] disable SMM access to SpeedStep using ACPI-FADT pstate_cnt
> prepared an updated version, will submit for 2.6.9.
Ok.
Thanks for the summary 8-)
Dave
next prev parent reply other threads:[~2004-08-02 19:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-27 20:51 post-OLS pending cpufreq patches Dominik Brodowski
2004-07-28 13:59 ` Dave Jones
2004-07-28 17:25 ` Dominik Brodowski
2004-08-02 19:33 ` Dave Jones [this message]
2004-08-02 20:40 ` Dominik Brodowski
2004-08-02 20:42 ` Dominik Brodowski
2004-08-02 20:52 ` Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2004-08-02 22:45 Pallipadi, Venkatesh
2004-08-03 12:42 ` Dominik Brodowski
2004-08-03 13:17 ` Dave Jones
2004-08-03 13:30 ` Dominik Brodowski
2004-08-03 13:37 ` Dave Jones
2004-08-03 14:07 ` Dominik Brodowski
2004-08-03 14:19 ` Dave Jones
2004-08-03 15:06 Pallipadi, Venkatesh
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=20040802193350.GA15740@redhat.com \
--to=davej@redhat.com \
--cc=cpufreq@www.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.