Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Oct 2002 20:36:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Oct 2002 20:35:48 -0400 Received: from ylug.mozilla.gr.jp ([203.141.142.92]:33029 "HELO maison.kyo-ko.org") by vger.kernel.org with SMTP id ; Mon, 21 Oct 2002 20:35:09 -0400 X-Mailer: cmail 2.61.1+20011011 on GNU Emacs 20.7.2 / Mule 4.1 =?ISO-2022-JP?B?KBskQjAqGyhCKQ==?= References: <20021017171217.4749211782A@triton2> <1035209178.27318.118.camel@irongate.swansea.linux.org.uk> From: Hiroshi Miura To: alan@lxorguk.ukuu.org.uk Cc: miura@da-cha.org, davej@suse.de, hpa@zytor.com, linux-kernel@vger.kernel.org In-reply-to: Alan Cox's message of "21 Oct 2002 15:06:18 +0100" <1035209178.27318.118.camel@irongate.swansea.linux.org.uk> Subject: Re: NatSemi Geode improvement X-Face: "7/]{D;9O-#dR'kB\tvpz_:#o|*UdC.KK/_"IN*i5VTU&EBhS6w68xQDPh]i4N%1byZ~v~X k$vdp(%V@gY!_|7x7Ht)^ih5\%\l'hcl$`sqp;%`boxPHDJB<~Sr8(e:zPKmeZ)ZPml[0v\|[V00Jm G,%5V5X9Mw7j}(8+!o>&&wmQ]Xh=j User-Agent: SEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNW0lTkMrGyhC?=) FLIM/1.14.3 (=?ISO-2022-JP?B?GyRCQCZLNThmTk1BMBsoQg==?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (=?ISO-2022-JP?B?GyRCMCobKEI=?=) MIME-Version: 1.0 (generated by SEMI 1.14.3 - =?ISO-2022-JP?B?IhskQjVtGyhC?= =?ISO-2022-JP?B?GyRCJU5DKxsoQiI=?=) Content-Type: text/plain; charset=US-ASCII Message-Id: <20021022001248.3F70A117B00@triton2> Date: Tue, 22 Oct 2002 09:12:48 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2557 Lines: 64 In message "Re: NatSemi Geode improvement" on 02/10/21, Alan Cox writes: > > + printk(KERN_INFO "Enable Memory access reorder on Cyrix/NSC processor.\n"); > > + local_irq_save(flags); > > + ccr3 = getCx86(CX86_CCR3); > > + setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */ > > + /* Load/Store Serialize to mem access disable (=reorder it) */ > > + setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80); > > +#ifdef CONFIG_NOHIGHMEM > > + /* set load/store serialize from 1GB to 4GB */ > > + ccr3 |= 0xe0; > > +#endif > > + setCx86(CX86_CCR3, ccr3); > > I dont think this is safe. You now need store fences on bus mastering > DMA. You should be able to reuse the IDT winchip code for that - I set > the winchip up for weak store ordering too, and its a big win (I also > saw about 30% on block copies) Winchip C6 MCR is like to intel MTRR and Cyrix 6x86MX ARR. Geode has NO similar registers and only has serialize flags to 1-2GB,2-3GB,3-4GB which are the CCR3's MSB bits. Geode is always serialize the 640KB-1MB area. The read/write reordering and the read bypassing are handled by geode MMU. It means that mmio must map to over 1GB area or disable this feature. for example, on my geode machine, $ cat /proc/iomem 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-09d7ffff : System RAM 00100000-001e7ce2 : Kernel code 001e7ce3-0022a857 : Kernel data 10000000-10000fff : Ricoh Co Ltd RL5c475 10000000-10000fff : i82365 40010000-40010fff : Cyrix Corporation 5520 [Cognac] 60000000-60000fff : card services e0000000-e0000fff : Compaq Computer Corporation ZFMicro Chipset USB e0000000-e0000fff : usb-ohci ffff0000-ffffffff : reserved (this sample is on linux-2.4.19-pre10-ac2) with this, this patch may safe in this condition. anyway, this reorder setting can be done by 'set6x86' tool, so user can decide in user space whether use the mem re-ordering or not. Hiroshi Miura --- http://www.da-cha.org/ NTTDATA Corp. Marketing & Business Strategy Planning Dept. --- miurahr@nttdata.co.jp Key fingerprint = 9117 9407 5684 FBF1 4063 15B4 401D D077 04AB 8617 -- My hacking life is happy as the day is long - 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/