Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932316AbVJCSeE (ORCPT ); Mon, 3 Oct 2005 14:34:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932512AbVJCSeE (ORCPT ); Mon, 3 Oct 2005 14:34:04 -0400 Received: from [81.2.110.250] ([81.2.110.250]:42727 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S932316AbVJCSeC (ORCPT ); Mon, 3 Oct 2005 14:34:02 -0400 Subject: Re: [PATCH 1/7] AMD Geode GX/LX support From: Alan Cox To: Jordan Crouse Cc: linux-kernel@vger.kernel.org In-Reply-To: <20051003174738.GC29264@cosmic.amd.com> References: <20051003174738.GC29264@cosmic.amd.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 03 Oct 2005 20:01:49 +0100 Message-Id: <1128366109.26992.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1878 Lines: 58 On Llu, 2005-10-03 at 11:47 -0600, Jordan Crouse wrote: > + - "Geode GX" for AMD Geode GX processors > - "Crusoe" for the Transmeta Crusoe series. > - "Efficeon" for the Transmeta Efficeon series. > - "Winchip-C6" for original IDT Winchip. Whats wrong with the existing MGEODEGX1 define (other than it doesn't say AMD) > config X86_USE_3DNOW > bool > - depends on MCYRIXIII || MK7 > + depends on MCYRIXIII || MK7 || MGEODE_GX > default y Is this correct - last time I benchmarked it the older GEODE was better off using non MMX copies ? > > config X86_OOSTORE > @@ -532,7 +539,7 @@ source "kernel/Kconfig.preempt" > > config X86_UP_APIC > bool "Local APIC support on uniprocessors" > - depends on !SMP && !(X86_VISWS || X86_VOYAGER) > + depends on !SMP && !(X86_VISWS || X86_VOYAGER || MGEODE_GX) > help This is wrong - a GEODE kernel can support APIC even if the Geode itself doesn't. Remeber it is *optimised for at least... * not "xyz only" > + depends on !MGEODE_GX > help > Select this if you have a 32-bit processor and more than 4 > gigabytes of physical RAM. Ditto > + clear_bit(0*32+16, &c->x86_capability); > + clear_bit(0*32+24, &c->x86_capability); > + > + since I don't think the kernel supports > + FPU-CMOV or Cyrix MMX. Unsure tho. Kernel space enables Cyrix MMX on the processors it knows about that it can. Some userspace will use the extensions if present. The Cyrix init code you unplugged it from knows how to do this which your unfinished patch doesn't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/