- Rename REG_DL to REG_DLL and REG_DLH.
- Always treat DLL and DLH as two separate 8-bit registers instead of one
16-bit register.
Additionally, remove the probe for the high 4 bits of IER being 0 and don't
assume we can always read/write 0 to/from those bits.
These changes allow uart(4) to drive the UARTs on the Intel XScale PXA255.
Reviewed by: marcel
divisor. This allows us to set the line speed to the maximum
of 1/4 of the device clock.
o Disable the baudrate generator before programming the line
settings, including baudrate, and enable it afterwards.
o Properly use rman(9) to manage resources. This eliminates the
need to puc-specific hacks to rman. It also allows devinfo(8)
to be used to find out the specific assignment of resources to
serial/parallel ports.
o Compress the PCI device "database" by optimizing for the common
case and to use a procedural interface to handle the exceptions.
The procedural interface also generalizes the need to setup the
hardware (program chipsets, program clock frequencies).
o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by
default and non-serdev devices are handled by the bus.
o Use the serdev I/F to collect interrupt status and to handle
interrupts across ports in priority order.
o Sync the PCI device configuration to include devices found in
NetBSD and not yet merged to FreeBSD.
o Add support for Quatech 2, 4 and 8 port UARTs.
o Add support for a couple dozen Timedia serial cards as found
in Linux.
the NS8250 class driver. The UART has FIFOs if sc_rxfifosz>1, so
test for that instead.
While here properly initialize sc_rxfifosz and sc_txfifosz in the
case the UART doesn't have FIFOs.
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
interrupt handlers rather than BUS_SETUP_INTR() and BUS_TEARDOWN_INTR().
Uses of the BUS_*() versions in the implementation of foo_intr methods
in bus drivers were not changed. Mostly this just means that some
drivers might start printing diagnostic messages like [FAST] when
appropriate as well as honoring mpsafenet=0.
- Fix two more of the ppbus drivers' identify routines to function
correctly in the mythical case of a machine with more than one ppbus.
Control) devices as console. These are microcontrollers which are either
on-board or part of an add-on card and provide terminal server, remote
power switch and monitoring functionality. For console usage these are
connected to the rest of the system via a SCC or an UART. This commit adds
support for the following variants (corresponds to what 'input-device' and
'output-device' have to be set to):
rsc found on-board in E250 and supposedly some Netra, connected
via a SAB82532, com. parameters can be determined via OFW
rsc-console RSC card found in E280R, Fire V4x0, Fire V8x0, connected
via a NS16550, hardwired to 115200 8N1
lom-console LOMlite2 card found in Netra 20/T4, connected via a NS16550,
hardwired to 9600 8N1
- Add my copyright to uart_cpu_sparc64.c as I've rewritten about one third
of that file over time.
Tested on: E250, E280R
Thanks to: dwhite@ for providing access to an E280R
OK'ed by: marcel
MFC after: 1 week
compilation of kernels without ns8250 support but using the uart framework.
These kernels will be for machines where size matters more, so including code
that can never be executed is undesriable...
o Fix typo in comment
o s/-100/BUS_PROBE_GENERIC/
o s/err/error/ for consistency
o Remove non-applicable comment
o Allow uart_bus_probe() to return the predefined BUS_PROBE_*
contants. In this case: explicitly test for error > 0.
o Oxford Semiconductor PCI Dual Port Serial
o Netmos Nm9845 PCI Bridge with Dual UART
Add PCI IDs for single-port cards:
o Various SIIG Cyber Serial
o Oxford Semiconductor OXCB950 UART
Update description as per puc(4).
and increase flexibility to allow various different approaches to be tried
in the future.
- Split struct ithd up into two pieces. struct intr_event holds the list
of interrupt handlers associated with interrupt sources.
struct intr_thread contains the data relative to an interrupt thread.
Currently we still provide a 1:1 relationship of events to threads
with the exception that events only have an associated thread if there
is at least one threaded interrupt handler attached to the event. This
means that on x86 we no longer have 4 bazillion interrupt threads with
no handlers. It also means that interrupt events with only INTR_FAST
handlers no longer have an associated thread either.
- Renamed struct intrhand to struct intr_handler to follow the struct
intr_foo naming convention. This did require renaming the powerpc
MD struct intr_handler to struct ppc_intr_handler.
- INTR_FAST no longer implies INTR_EXCL on all architectures except for
powerpc. This means that multiple INTR_FAST handlers can attach to the
same interrupt and that INTR_FAST and non-INTR_FAST handlers can attach
to the same interrupt. Sharing INTR_FAST handlers may not always be
desirable, but having sio(4) and uhci(4) fight over an IRQ isn't fun
either. Drivers can always still use INTR_EXCL to ask for an interrupt
exclusively. The way this sharing works is that when an interrupt
comes in, all the INTR_FAST handlers are executed first, and if any
threaded handlers exist, the interrupt thread is scheduled afterwards.
This type of layout also makes it possible to investigate using interrupt
filters ala OS X where the filter determines whether or not its companion
threaded handler should run.
- Aside from the INTR_FAST changes above, the impact on MD interrupt code
is mostly just 's/ithread/intr_event/'.
- A new MI ddb command 'show intrs' walks the list of interrupt events
dumping their state. It also has a '/v' verbose switch which dumps
info about all of the handlers attached to each event.
- We currently don't destroy an interrupt thread when the last threaded
handler is removed because it would suck for things like ppbus(8)'s
braindead behavior. The code is present, though, it is just under
#if 0 for now.
- Move the code to actually execute the threaded handlers for an interrrupt
event into a separate function so that ithread_loop() becomes more
readable. Previously this code was all in the middle of ithread_loop()
and indented halfway across the screen.
- Made struct intr_thread private to kern_intr.c and replaced td_ithd
with a thread private flag TDP_ITHREAD.
- In statclock, check curthread against idlethread directly rather than
curthread's proc against idlethread's proc. (Not really related to intr
changes)
Tested on: alpha, amd64, i386, sparc64
Tested on: arm, ia64 (older version of patch by cognet and marcel)
which serial device to use in that case respectively to not rely on
the OFW names of the input/output and stdin/stdout devices. Instead
check whether input and output refers to the same device and is of
type serial (uart(4) was already doing this) and for the fallback
to a serial console in case a keyboard is the selected input device
but unplugged do the same for stdin and stdout in case the input
device is nonexistent (PS/2 and USB keyboards) or has a 'keyboard'
property (RS232 keyboards). Additionally also check whether the OFW
did a fallback to a serial console in the same way in case the
output device is nonexistent. While at it save on some variables
and for sys/boot/sparc64/loader/metadata.c move the code in question
to a new function md_bootserial() so it can be kept in sync with
uart_cpu_getdev_console() more easily.
This fixes selecting a serial console and the appropriate device
when using a device path for the 'input-device' and 'output-device'
OFW environment variables instead of an alias for the serial device
to use or when using a screen alias that additionally denotes a
video mode (like e.g. 'screen:r1024x768x60') but no keyboard is
plugged in (amongst others). It also makes the code select a serial
console in case the OFW did the same due to a misconfiguration like
both 'input-device' and 'output-device' set to 'keyboard' or to a
nonexisting device (whether the OFW does a fallback to a serial
console in case of a misconfiguration or one ends up with just no
console at all highly depends on the OBP version however).
- Reduce the size of buffers that only ever need to hold the string
'serial' accordingly. Double the size of buffers that may need to
hold a device path as e.g. '/pci@8,700000/ebus@5/serial@1,400000:a'
exceeds 32 chars.
- Remove the package handle of the '/options' node from the argument
list of uart_cpu_getdev_dbgport() as it's unused there and future
use is also unlikely.
MFC after: 1 week
not only means that it's possible (though unlikely) that we hand out
differing tags for the same bus space, it also means that the tags
we handed out are not used during bus enumeration. Both affect our
ability to compare tags. Fix the first by initializing our tags only
once. Fix the second by testing if one of the tags to compare is our
tag and the other is a busspace_isa_{io|mem} tag and declare them
equal if so.
This fixes using uart(4) as the serial console on a ds10. That is,
the low-level console worked, but we could not match the resources
to one of the UARTs found during bus enumeration, which prevented
uart(4) from becoming the console in single- or multi-user mode.
Approved by: re (kensmith)
MFC after: 2 days
Thanks to: all involved in getting a ds10 to me; directly or indirectly.
Special thanks to: Dave Knight, ISC (for not scratching my Porsche :-)
times which was added in the last revision with what should be a proper
solution as long as keyboards that were pluggged in after the kernel
has fully booted aren't supported. I.e. when sunkbd_configure() is
called for the high-level console probe make sure that the keyboard is
both successfully configured (i.e. also probed) and attached. The band-
aid left the possibility to attach the keyboard device to the high-level
console without attaching the keyboard device itself when the keyboard
is plugged in after uart(4) attached but before syscons(4) does.
share their IRQ lines with the i8042. Any IRQ activity (typically during
attach) on the NS16550 used to connect the keyboard when actually the
PS/2 keyboard is selected in OFW causes interaction with the OBP i8042
driver resulting in a hang (and vice versa). As RS232 keyboards and mice
obviously aren't meant to be used in parallel with PS/2 ones on these
boards don't attach to these NS16550 in case the RS232 keyboard isn't
selected in order to prevent such hangs.
Ok'ed by: marcel
UARTs used to connect keyboards and not also PS/2 keyboards and only
return their package handle in case the keyboard is the preferred one
according to the OFW but otherwise still regardless of whether the
keyboard is used for stdin or not. This is simply achieved by looking
at the 'keyboard' alias and returning the corresponding package handle
in case it refers to a SCC/UART. This is change is done in order to
give the keyboard which the OFW or the user selected in OFW on boards
that support additional types of keyboards besides the RS232 ones also
preference in FreeBSD. It will be also used to determine on Sun AXi and
Sun AXmp boards whether a PS/2 or a RS232 is to be used as these are
sort of mutual exclusive there (see upcoming commit to uart_bus_ebus.c).
Note that Tatung AXi boards have the same issue but the former code
happened to already give the PS/2 keyboard preference by not identifying
the respective UART as keyboard system device there because the PS/2
keyboard node precedes the keyboard UART one in the OFW device tree of
these boards (which isn't the case for the Sun AXi).
Ok'ed by: marcel
a band-aid allowing to call this function savely multiple times, e.g.
during sckbdprobe() and sc_probe_unit(). Otherwise calling it a second
time results in a non-working keyboard. This needs a lot of more work
to actually do the right thing and work like expected.
- Let sunkbd_configure() return the number of the found keyboards, i.e.
1 in case probing succeeds, as it's expected. The return values of the
keyboard configure functions however currently aren't checked so this
doesn't make a difference at the moment.
- Use FBSDID.
The core console code checks this field when a console is added and
emits a warning if it's empty. In practice the warning is harmless for
uart(4), because the cn_name is filled in as soon as the device name is
known; which is when the device is enumerated.
To avoid the warning, to avoid possible complications caused by emitting
the warning without there (possibly) being a console selected yet and to
avoid complications when the UART isn't found during bus enumeration, we
just preset the cn_name field here to the name of the driver.
fact that access to RR0 does not need a prior write to the register
index because the index always reverts to 0 after the indexed register
has been accessed.
Typically when a RR or WR is to accessed, one programs the index (which
is a write to the control register), followed by a read or write to the
actual indexed register (a read pr write to the same control register).
When this non-atomic sequence is interrupted after having written the
index and low-level console I/O is done in that situation, the write to
program the index will actually write to the indexed register and nuke
state. This almost always yields a wedge.
By not programming the index register and instead just reading from RR0,
the worst case scenario is non-fatal. For if we don't actually read from
RR0 but some other register we get an invalid status, which may lead us
to conclude that the transit data register is empty when it's not or that
the receive data register contains data when it doesn't. Hence, we may
lose an output character or get a sporadic input character, but given
the situation this is a non-issue.
Full serialization is not possible due to the fact that this code needs
to work from DDB and before mutex initialization has happened.
In collaboration with: kris@, marius@
Tested by: kris@
MFC after: 1 day
X-MFC: 5.4-RELEASE candidate
a serial console anyway because input-device is set to keyboard and
output-device is set to screen but no keyboard is plugged in don't
assume that a device node for the input-device alias exists. While
this is true for RS232 keyboards (the node of the SCC and UART
respectively which controls the keyboard doesn't disappear when no
keyboard is plugged in) this assumption breaks for USB keyboards.
It's most likely also not true for PS/2 keyboards but OFW doesn't
reliably switch to a serial console when the potential keyboard is
a PS/2 one which isn't plugged in so this couldn't be verified
properly.
Reported by: Will Andrews <will@csociety.org>, obrien
MFC after: 1 week
with shared IRQs in case the bus code, MD interrupt code, etc. permits.
Together with sys/sparc64/sparc64/intr_machdep.c rev. 1.21 this fixes
an endless loop in uart_intr() when using the second NS16550 on the ISA
bus of sparc64 machines.
- Destroy the hardware mutex on detach and in case attaching fails.
Approved by: marcel
for nodes hanging off of Central (untested), FireHose (untested) and
PCI (tested) busses.
- Add an additional parameter to OF_decode_addr() which specifies the
index of the register bank to decode.
These should allow to eventually add support for the Z8530 hanging off of
FireHose to uart(4) and to write support for PCI-based graphics adapters.
Suggested by: tmm (back in '03)
The presence or absence of a keyboard does not change whether an
UART is designed as a keyboard port or not and thus whether we
can use the port as a TTY or not.
We now call sunkbd_attach() even when we didn't previously find
a keyboard. Emit a useful message stating that no keyboard was
found, but don't do anything else.
MFC after: 5 days
