- 05 9月, 2008 1 次提交
-
-
由 Yinghai Lu 提交于
1. add c_x86_vendor into cpu_dev 2. change cpu_devs to static 3. check c_x86_vendor before put that cpu_dev into array 4. remove alignment for 64bit 5. order the sequence in cpu_devs according to link sequence... so could put intel at first, then amd... Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 28 8月, 2008 1 次提交
-
-
由 H. Peter Anvin 提交于
We have had a number of cases where <asm/cpufeature.h> (and its predecessors) have diverged substantially from the names list in /proc/cpuinfo. This patch generates the latter from the former. It retains the option for explicitly overriding the strings, but by making that require a separate action it should at least be less likely to happen. It would be good to do a future pass and rename strings that are gratuituously different in the kernel (/proc/cpuinfo is a userspace interface and must remain constant.) Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 18 8月, 2008 2 次提交
-
-
由 Thomas Petazzoni 提交于
This patch adds some configuration options that allow to compile out CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The new configuration options are only visible when CONFIG_EMBEDDED is selected, as they are mostly interesting for space savings reasons. An example of size saving, on x86 with only Intel CPU support: text data bss dec hex filename 1125479 118760 212992 1457231 163c4f vmlinux.old 1121355 116536 212992 1450883 162383 vmlinux -4124 -2224 0 -6348 -18CC +/- However, I'm not exactly sure that the Kconfig wording is correct with regard to !64BIT / 64BIT. [ mingo@elte.hu: convert macro to inline ] Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Petazzoni 提交于
arch/x86/kernel/cpu/intel.c defines a few fallback functions (cmpxchg_*()) that are used when the CPU doesn't support cmpxchg and/or cmpxchg64 natively. However, while defined in an Intel-specific file, these functions are also used for CPUs from other vendors when they don't support cmpxchg and/or cmpxchg64. This breaks the compilation when support for Intel CPUs is disabled. This patch moves these functions to a new arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when X86_32 is enabled. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: michael@free-electrons.com Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 7月, 2008 1 次提交
-
-
由 Yinghai Lu 提交于
Signed-off-by: NYinghai Lu <yhlu.kernel@mail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 6月, 2008 1 次提交
-
-
由 Hiroshi Shimamoto 提交于
It looks good to move bugs_64.c to cpu/bugs_64.c. Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 31 5月, 2008 3 次提交
-
-
由 Dave Jones 提交于
Create a separate centaur_64.c file in the cpu/ dir for the useful parts to live in. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Dave Jones 提交于
Create a separate intel_64.c file in the cpu/ dir for the useful parts to live in. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Dave Jones 提交于
Create a separate amd_64.c file in the cpu/ dir for the useful parts to live in. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 26 4月, 2008 1 次提交
-
-
由 Dmitri Vorobiev 提交于
It is claimed that NexGen CPUs were never shipped: http://lkml.org/lkml/2008/4/20/179 Also, the kernel support for these chips has been broken for a long time, the code intended to support NexGen thereby being essentially dead. As an outcome of the discussion that can be found using the URL above, this patch removes the NexGen support altogether. The changes in this patch survived a defconfig build for i386, a couple of successful randconfig builds, as well as a runtime test, which consisted in booting a 32-bit x86 box up to the shell prompt. Signed-off-by: NDmitri Vorobiev <dmitri.vorobiev@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 17 4月, 2008 2 次提交
-
-
由 Hiroshi Shimamoto 提交于
Now cpu/proc.c and cpu/proc_64.c are same. So cpu/proc_64.c can be removed. Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Hiroshi Shimamoto 提交于
x86 /proc/cpuinfo code can be unified. This is the first step of unification. Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 2月, 2008 1 次提交
-
-
由 H. Peter Anvin 提交于
Move the CPU feature string names to a separate file (common to 32 and 64 bits); additionally, make <asm/cpufeature.h> includable by host code in preparation for including the CPU feature strings in the boot code. Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 24 10月, 2007 1 次提交
-
-
由 Thomas Gleixner 提交于
Prepare the makefiles in x86/kernel/cpu and x86/kernel/cpu/mcheck to be used by the x86_64 build as well. No code change. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 11 10月, 2007 5 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 22 7月, 2007 1 次提交
-
-
由 Adrian Bunk 提交于
The Rise CPUs were only very short-lived, and there are no reports of anyone both owning one and running Linux on it. Googling for the printk string "CPU: Rise iDragon" didn't find any dmesg available online. If it turns out that against all expectations there are actually users reverting this patch would be easy. This patch will make the kernel images smaller by a few bytes for all i386 users. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Acked-by: NDave Jones <davej@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 7月, 2007 1 次提交
-
-
由 Venki Pallipadi 提交于
Some Intel features are spread around in different CPUID leafs like 0x5, 0x6 and 0xA. Make this feature detection code common across i386 and x86_64. Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver. Refer to Intel Software Developer's Manual for more details about the feature. Thanks to hpa (H Peter Anvin) for the making the actual code detecting the scattered features data-driven. Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 5月, 2007 2 次提交
-
-
由 Andi Kleen 提交于
- Introduce a wd_ops structure - Convert the various nmi watchdogs over to it - This allows to split the perfctr reservation from the watchdog setup cleanly. - Do perfctr reservation globally as it should have always been - Remove dead code referenced only by unused EXPORT_SYMBOLs Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Jeremy Fitzhardinge 提交于
Most of asm-i386/bugs.h is code which should be in a C file, so put it there. Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-