Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements
"M. Warner Losh" <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm,gmane.os.freebsd.devel.mobile,gmane.os.freebsd.current |
|---|---|
| Message-ID | <[email protected]> |
In message: <[email protected]> Taku YAMAMOTO <[email protected]> writes: : On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) : "M. Warner Losh" <[email protected]> wrote: : : > In message: <[email protected]> : > Alexander Motin <[email protected]> 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. That would cause the problem. If we're bogusly adjusting tsc_freq we should fix that... Warner _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"