Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements

[Taku YAMAMOTO <taku_(_at_)_tackymt_(_dot_)_homeip_(_dot_)_net>]

On Thu, 16 Oct 2008 09:28:44 -0600 (MDT)
"M. Warner Losh" <imp_(_at_)_bsdimp_(_dot_)_com> wrote:

> In message: <48F75773_(_dot_)_7030100_(_at_)_FreeBSD_(_dot_)_org>
>             Alexander Motin <mav_(_at_)_FreeBSD_(_dot_)_org> 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
 | __ <     <taku_(_at_)_tackymt_(_dot_)_homeip_(_dot_)_net>

      - A chicken is an egg's way of producing more eggs. -
_______________________________________________
freebsd-mobile_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "freebsd-mobile-unsubscribe_(_at_)_freebsd_(_dot_)_org"