svn commit: r186520 - head/sys/dev/puc
Bruce Evans
brde at optusnet.com.au
Thu Jan 1 12:29:58 UTC 2009
On Thu, 1 Jan 2009, M. Warner Losh wrote:
> In message: <495B406F.2040305 at localhost.inse.ru>
> Roman Kurakin <rik at inse.ru> writes:
> : Probably we need to implement AUTODETECT_RCLK. I've had the patch,
> : but it worked only for modules, cause there was no working timers while the
> : cards probe time if the driver was compiled in. I've planned to move
> : detection
> : code to the first open and do some cleanup after the detection, but
> : didn't do
> : that.
>
> I'd like to see that. I think we can defer the detection of RCLK to
> later. How accurate is this, btw? How dependent on timing of
> interrupts is it?
This cannot work in the following cases:
- serial consoles. The device is then used as a low-level console
long before the first open and in a context where timer interrupts
are unavailable even if timers are initialized. However, at least
on i386's, the main (i8254) timer is initialized just before
console initialization (which is just before the first possible use
of a console (for booting with -d)), to support the syscons driver
using DELAY() which requires the timer to be initialized. DELAY()
is probably sufficient for detecting RCLK if it is possible to
detect RCLK at all (set the speed low enough so that polling every
millisecond after DELAY(1000) is good enough).
- emulated hardware. The emulation only needs to emulate the specified
speed on the external interface. It would take an unreasonably high
quality emulation to get the timing right in all cases, especially
for the loopback case which should be used here. In the loopback
case, the external interface hardware would not even be used, except
part of the unreasonably high quality implementation would involve
using the external interface to the extent of telling it to do nothing
except return its timing signals so that the looped back input arrives
at the same time as it would on the other side of the external interface
if it weren't looped back.
Bruce
More information about the svn-src-head
mailing list