From owner-freebsd-arm@FreeBSD.ORG Thu Oct 16 17:25:38 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 0CAF3106569A; Thu, 16 Oct 2008 17:25:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id D02A28FC16; Thu, 16 Oct 2008 17:25:36 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 225242339; Thu, 16 Oct 2008 20:25:35 +0300 Message-ID: <48F7790F.5000904@FreeBSD.org> Date: Thu, 16 Oct 2008 20:25:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Taku YAMAMOTO References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> <20081017013946.3534221e.taku@tackymt.homeip.net> In-Reply-To: <20081017013946.3534221e.taku@tackymt.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 17:25:38 -0000 Taku YAMAMOTO wrote: > 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. Indeed: CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 FreeBSD 8.0-CURRENT amd64. -- Alexander Motin