On Thu, May 24, 2007 at 05:04:13PM -0700, H. Peter Anvin wrote:
>
> If they grow slowly from the bottom, I guess we could simply allocate
> space in the vector byte by byte instead. Either way, it means more
> work whenever anything has to change.
>
hpa,
Below patch adds a new word for feature
Pallipadi, Venkatesh wrote:
> The way new Intel features are being exposed in CPUID is kind of
> changing.
Changing is a VERY BAD THING when it comes to something like CPUID.
> Now we have different CPUID leafs for different kind of features with
> each of them growing much slowly.
> I mean, ther
>-Original Message-
>From: H. Peter Anvin [mailto:[EMAIL PROTECTED]
>Sent: Thursday, May 24, 2007 4:23 PM
>To: Pallipadi, Venkatesh
>Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel
>Subject: Re: [PATCH] Display Intel Dynamic Acceleration
>fea
Alan Cox wrote:
>
> The older AMD docs (CPU rev guide) list bit 31 of both 0x8001 and
> 0x0001 as 3dnow
>
> All their example code/docs say to use 0x8001
>
I don't have access to any AM2 systems, but the bit is definitely set on
socket 939 Athlon X2 ("model 43").
-hpa
-
To
On Thu, 24 May 2007 18:41:54 -0400
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Thu, May 24, 2007 at 03:14:39PM -0700, H. Peter Anvin wrote:
>
> > pbe collides with abuse by at least two vendors (AMD and
> > Cyrix/Centaur/VIA) of this bit for 3DNow.
>
> Unless I'm mistaken,
>
> pbe comes from c
Pallipadi, Venkatesh wrote:
>
> Yes. But it only has 3 features defined right now. 2 in EAX and one in
> ECX. Should I use 2 new words for these bits or just use the software
> defined bits as in my earlier patch?
>
Oh for heaven's sake. Could you please do the world a favour and shoot
your CPU
>-Original Message-
>From: H. Peter Anvin [mailto:[EMAIL PROTECTED]
>Sent: Thursday, May 24, 2007 4:04 PM
>To: Pallipadi, Venkatesh
>Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel
>Subject: Re: [PATCH] Display Intel Dynamic Acceleration
>fea
Dave Jones wrote:
> On Thu, May 24, 2007 at 03:51:31PM -0700, H. Peter Anvin wrote:
> > What you're describing is correct for later-level AMD/Cyrix chips,
> > however, when 3DNow! was first introduced they foolishly squatted on the
> > Intel-assigned CPUID flags.
>
> Hmm, the 3dnow spec (doc 21
On Thu, May 24, 2007 at 03:51:31PM -0700, H. Peter Anvin wrote:
> What you're describing is correct for later-level AMD/Cyrix chips,
> however, when 3DNow! was first introduced they foolishly squatted on the
> Intel-assigned CPUID flags.
Hmm, the 3dnow spec (doc 21928e) has it in the right plac
Venki Pallipadi wrote:
>
> I can do it in intel setup function. But, the feature may not be activated
> unless the driver is loaded. Going by the hardware capability point
> of view, we can do it in setup function.
>
> The feature appears in CPUID 6 (called Power Management Leaf) instead of
> reg
Dave Jones wrote:
> On Thu, May 24, 2007 at 03:14:39PM -0700, H. Peter Anvin wrote:
>
> > pbe collides with abuse by at least two vendors (AMD and
> > Cyrix/Centaur/VIA) of this bit for 3DNow.
>
> Unless I'm mistaken,
>
> pbe comes from cpuid level 1
>
> 3dnow comes from cpuid level 0x800
On Thu, May 24, 2007 at 03:14:39PM -0700, H. Peter Anvin wrote:
> pbe collides with abuse by at least two vendors (AMD and
> Cyrix/Centaur/VIA) of this bit for 3DNow.
Unless I'm mistaken,
pbe comes from cpuid level 1
3dnow comes from cpuid level 0x8001
though I did notice that amd have it
Andrew Morton wrote:
>
> @@ -23,13 +23,14 @@ static int show_cpuinfo(struct seq_file
> "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
> "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
> "pat", "pse36", "pn", "clflush", NULL, "dts",
Venki Pallipadi wrote:
>
> Hmm.. Will move feature detection to setup routines and will also
> refresh the patch against latest mm and resend it
>
If you could send a patch against my git.newsetup instead, I'll merge
into that tree.
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newset
Andrew Morton wrote:
>
> I'm not sure I can be bothered repairing all that at present. I think I'll
> go and hide until it becomes somebody else's problem.
>
I'll fix it.
>
>
> @@ -23,13 +23,14 @@ static int show_cpuinfo(struct seq_file
> "fpu", "vme", "de", "pse", "tsc", "m
On Thu, May 24, 2007 at 03:02:23PM -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 15:46:37 -0700
> Venki Pallipadi <[EMAIL PROTECTED]> wrote:
>
> > Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
> > will be enabled automatically by current acpi-cpufreq driver and cpuf
On Wed, 23 May 2007 15:46:37 -0700
Venki Pallipadi <[EMAIL PROTECTED]> wrote:
> Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
> will be enabled automatically by current acpi-cpufreq driver and cpufreq.
>
> Refer to Intel Software Developer's Manual for more details abo
> I can do it in intel setup function. But, the feature may not be activated
> unless the driver is loaded.
That would put users in a chicken and egg situation: they cannot know they
need to load a driver to go faster. It's better to display it always.
-Andi
-
To unsubscribe from this list: send
On Thu, May 24, 2007 at 02:28:06PM -0700, Venki Pallipadi wrote:
> > But actually reading the patch: it seems weird to detect the flag
> > in acpi-cpufreq and essentially change /proc/cpuinfo when a
> > module is loaded. Why not in the intel setup function? And why is it
> > not in the stand
On Thu, May 24, 2007 at 11:25:27PM +0200, Andi Kleen wrote:
> On Thursday 24 May 2007 23:13:37 Venki Pallipadi wrote:
> > On Thu, May 24, 2007 at 11:08:38PM +0200, Andi Kleen wrote:
> > >
> > > I think it's generally a good idea to push cpuinfo flags in earliest
> > > as possible; just make sure w
On Thursday 24 May 2007 23:13:37 Venki Pallipadi wrote:
> On Thu, May 24, 2007 at 11:08:38PM +0200, Andi Kleen wrote:
> >
> > I think it's generally a good idea to push cpuinfo flags in earliest
> > as possible; just make sure we actually use the final name (so that we
> > don't get
> > into a pn
On Thu, May 24, 2007 at 11:08:38PM +0200, Andi Kleen wrote:
>
> I think it's generally a good idea to push cpuinfo flags in earliest
> as possible; just make sure we actually use the final name (so that we don't
> get
> into a pni->sse3 mess again)
>
ida is official name as in the Software De
On Thu, May 24, 2007 at 05:01:04PM -0400, Dave Jones wrote:
> On Thu, May 24, 2007 at 01:55:13PM -0700, Andrew Morton wrote:
> > On Wed, 23 May 2007 15:46:37 -0700
> > Venki Pallipadi <[EMAIL PROTECTED]> wrote:
> >
> > > Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
On Thursday 24 May 2007 23:01:04 Dave Jones wrote:
> On Thu, May 24, 2007 at 01:55:13PM -0700, Andrew Morton wrote:
> > On Wed, 23 May 2007 15:46:37 -0700
> > Venki Pallipadi <[EMAIL PROTECTED]> wrote:
> >
> > > Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
> > > w
On Thu, May 24, 2007 at 01:55:13PM -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 15:46:37 -0700
> Venki Pallipadi <[EMAIL PROTECTED]> wrote:
>
> > Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
> > will be enabled automatically by current acpi-cpufreq driver and
On Wed, 23 May 2007 15:46:37 -0700
Venki Pallipadi <[EMAIL PROTECTED]> wrote:
> Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
> will be enabled automatically by current acpi-cpufreq driver and cpufreq.
So you're saying that the cpufreq code in Linus's tree aleady suppo
26 matches
Mail list logo
