From owner-freebsd-arm@FreeBSD.ORG Thu Oct 16 16:39:50 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E0D81065690; Thu, 16 Oct 2008 16:39:50 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 2D63E8FC0C; Thu, 16 Oct 2008 16:39:49 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id F12331075B; Fri, 17 Oct 2008 01:39:48 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMmGxc1yeZd7; Fri, 17 Oct 2008 01:39:46 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Fri, 17 Oct 2008 01:39:46 +0900 (JST) Date: Fri, 17 Oct 2008 01:39:46 +0900 From: Taku YAMAMOTO To: "M. Warner Losh" Message-Id: <20081017013946.3534221e.taku@tackymt.homeip.net> In-Reply-To: <20081016.092844.-1548243521.imp@bsdimp.com> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-mobile@freebsd.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org, zbeeble@gmail.com Subject: Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 16:39:50 -0000 On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) "M. Warner Losh" wrote: > In message: <48F75773.7030100@FreeBSD.org> > Alexander Motin writes: > : No, it's opposite. With lower frequency I have proportionally smaller > : delays (more loop iterations). I don't remember exact numbers now, but > : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - > : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor > : my eyes saw any visible delay there. > > You have more iterations. I'd have expected less. This doesn't say > anything at all about DELAY, per se. If you are waiting for 1M cycles > at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is > implemented by reading a counter in the 8254 that's been calibrated. > So unless the clock that's clocking it is running FASTER, delay won't > be the source of additional iterations. > > Hmmm, looking at the i386 delay code, it looks like it depends on > tsc_frequency being right when tsc isn't broken. If that's set > bogusly, that could cause DELAY to be slower... I have a Core 2 Duo whose TSC ticks regardless of how EST is set. In conjunction of tsc_freq_changed() function defined in tsc.c, tsc_freq becomes lower than actual, thus shorter DELAY(). Maybe his machine has the same. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. -