and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
belonged. Remove com_activate().
Consolidate information about the console on com(4) in a new struct
comcons_info.
Support detachment & re-attachment of a system console on com(4).
Re-attachment is somehow incomplete. Ideally, if some other device
could take over as console, it would, but we're not quite there,
yet.
register com_cleanup() as the shutdown hook.
Add a generic suspend routine. Suspend and resume com@isa.
Protect against dereferencing a NULL softc in comioctl().
Destroy both a mutex and a callout in com_detach().
Cosmetic: use aprint_*_dev(). Use PMF_FN_ARGS, PMF_FN_PROTO.
This allows us to convert aucom to just another com attachment, and cleanup
some code in the com_arbus.c.
Additionally, we use a common com_cleanup routine rather than having a
zillion copies of it in the attachment points.
This has been tested on a number architectures, and it has been shown to get
close to comparable performance when COM_REGMAP is defined, and comparable
when it is not defined.
Approved by core@. Fixes PR port-evbmips/32362.
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
and always call the simple_* locking functions. the locking functions
are compiled out if they are not needed anyway, so a separate option
for this doesn't gain anything.
this also fixes the serial console on my alpha ES40 (which doesn't make much
sense since the com driver should still be under the big lock on alpha,
but whatever).
com ports found on Intel PXA2x0 processors.
Re-arrange the code which detects the FIFO configuration to defer
printing until _after_ com_fifo is cleared. Some supposedly compatible
chips clear the Tx/Rx FIFOs when this happens, resulting in previous
output being lost.
not pre-load the chip's Tx buffer, but instead waits for the Tx Ready
interrupt to transmit the first chunk of data.
* On the IOP310, set COM_HW_NO_TXPRELOAD, rather than COM_HW_TXFIFO_DISABLE.
This solves the "UART hangs" problem on the Npwr in a nicer way (i.e. we
get to use the FIFO, whee). The COM_HW_NO_TXPRELOAD happens to match the
Linux 16550 driver's Tx algorithm, and the "UART hang" was never observed
on the Npwr running Linux.
Eventually, we might want to eliminate the COM_HW_NO_TXPRELOAD, and simply
always use its algorithm. But it should be tested on more 16x50 variants
before we do that.
Kudos to Valeriy Ushakov <uwe@netbsd.org> for pointing out this solution
(which also happens to fix the stray UART interrupt issue on the Krups
Javastation), and to Allen Briggs <briggs@netbsd.org> for experimenting
with various methods of fixing this.
- cominit() is local to com.c, remove prototype from comvar.h.
- Don't prototype comstop(), cdev_decl(com) does this.
- Don't use a block device switch table declaration(!).
- No need to include "com.h".
and place the definition in <machine/types.h>. This can now be used
as a flag to indicate whether or not <machine/intr.h> can be included
to get the generic soft interrupt API.
when running at splserial(). This is a temporary measure (until
there's a MP-safe interrupt handling structure); until then, it should
be used when MULTIPROCESSOR and IPL_SERIAL > IPL_SCHED.
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
This is useful in the case where an attachment's probe routine
verifies that there is indeed hardware present but something goes
"wrong" in the attach causing the device to be unusable. (Without
keeping track of this, in that case incorrect ports could be
accessed or uninitted pointers could be deferenced on open or at
other times.)
dyoung