svn commit: r186520 - head/sys/dev/puc
rik at inse.ru
Thu Jan 1 13:56:33 UTC 2009
Bruce Evans wrote:
> 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).
We can implement some sort of sysctl, hint or smth like this. I do not
think that AUTODETECT_RCLK should be used by default everywhere,
only in special cases. And for that cases it could be just to inform
about the value for the 'hint' to use.
> - 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
> if it weren't looped back.
Probably this is not the case. I doubt that emulated hardware should hit
such problems that it will need autodetction for it. Any way, if such
case will arise, such autodetection shouldn't not do more harm than it is.
More information about the svn-src-head