sys/dev/uart/uart_kbd_sun.c 1.10, 1.11 (partial), 1.13;
sys/dev/uart/uart_kbd_sun.h 1.3; sys/sparc64/conf/NOTES 1.30
- In sunkbd_probe_keyboard() don't bother to determine the keyboard layout
as we have no use for that info. Instead let this function return the
keyboard ID and verify at its invocation in sunkbd_configure() that we're
talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this
driver.
- Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective
code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to
emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by
kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also
triggers the use of AT keyboard maps and thus allows to use the map files
in share/syscons/keymaps with this driver at the cost of an additional
translation (in ukbd(4) this just is the way of operation).
- Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options
of the other keyboard drivers allows to specify the default in-kernel
keyboard map. For obvious reasons this made to only work when also using
SUNKBD_EMULATE_ATKBD.
- Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(),
which are also required for interoperability with kbdmux(4).
- Implement K_CODE mode and FreeBSD keypad compose.
- As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD
case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than
having to duplicate it and #ifdef some more code.
- Don't use the TX-buffer for writing the two command bytes for setting the
keyboard LEDs as this consequently requires a hardware FIFO that is at
least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't
have. Thus use an inlined version of uart_putc() to consecutively write
the command bytes (a cleaner approach would be to do this via the soft
interrupt handler but that variant wouldn't work while in ddb(4)). [1]
- Fix some minor style(9) bugs.
PR: 90316 [1]
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.
This is needed to get uart(4) to work on Xscale PXA255 and IXP425.
Do not try to call keyboard callback unless keyboard is active and busy.
This should fix 'kbdcontrol -K < /dev/console' panic on sparc64 with sunkbd(4).
PR: sparc64/96798
Approved by: re (hrs)
associated changes. More details below:
Remove public declarations of variables that were forgotten when they were
made static.
Revision Changes Path
1.31 +0 -1 src/sys/sys/interrupt.h
Make sure the interrupt is masked before processing it, or bad things
can happen.
Revision Changes Path
1.10 +3 -3 src/sys/arm/arm/intr.c
Reorganize the interrupt handling code a bit to make a few things cleaner
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)
Revision Changes Path
1.88 +43 -29 src/sys/alpha/alpha/interrupt.c
1.38 +5 -5 src/sys/alpha/isa/isa.c
1.16 +58 -52 src/sys/amd64/amd64/intr_machdep.c
1.6 +1 -1 src/sys/amd64/include/intr_machdep.h
1.16 +2 -2 src/sys/amd64/isa/atpic.c
1.11 +28 -22 src/sys/arm/arm/intr.c
1.462 +2 -2 src/sys/dev/sio/sio.c
1.6 +1 -1 src/sys/dev/uart/uart_kbd_sun.c
1.24 +2 -2 src/sys/dev/uart/uart_tty.c
1.15 +58 -52 src/sys/i386/i386/intr_machdep.c
1.8 +1 -1 src/sys/i386/include/intr_machdep.h
1.21 +2 -2 src/sys/i386/isa/atpic.c
1.52 +32 -25 src/sys/ia64/ia64/interrupt.c
1.180 +3 -2 src/sys/kern/kern_clock.c
1.127 +437 -270 src/sys/kern/kern_intr.c
1.206 +0 -1 src/sys/kern/subr_witness.c
1.6 +3 -3 src/sys/powerpc/include/intr_machdep.h
1.7 +35 -32 src/sys/powerpc/powerpc/intr_machdep.c
1.14 +1 -1 src/sys/sparc64/include/intr_machdep.h
1.24 +43 -36 src/sys/sparc64/sparc64/intr_machdep.c
1.32 +36 -36 src/sys/sys/interrupt.h
1.440 +1 -3 src/sys/sys/proc.h
Catch up with interrupt-thread changes.
Revision Changes Path
1.32 +1 -1 src/sys/dev/zs/zs.c
Catch up with new interrupt handling code.
Revision Changes Path
1.16 +3 -3 src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c
Catch up with new interrupt handling code.
Revision Changes Path
1.162 +2 -2 src/sys/dev/cy/cy.c
1.101 +2 -2 src/sys/dev/rc/rc.c
Catch up with new interrupt handling code.
Revision Changes Path
1.50 +2 -2 src/sys/dev/cx/if_cx.c
1.41 +1 -1 src/sys/dev/sab/sab.c
1.238 +2 -2 src/sys/pc98/cbus/sio.c
Add a swi_remove() function to teardown software interrupt handlers. For
now it just calls intr_event_remove_handler(), but at some point it might
also be responsible for tearing down interrupt events created via swi_add.
Revision Changes Path
1.128 +17 -0 src/sys/kern/kern_intr.c
1.33 +1 -0 src/sys/sys/interrupt.h
- Use swi_remove() to teardown swi handlers rather than
intr_event_remove_handler().
- Remove tty: prefix from a couple of swi handler names.
Revision Changes Path
1.51 +1 -1 src/sys/dev/cx/if_cx.c
1.102 +2 -2 src/sys/dev/rc/rc.c
1.42 +1 -1 src/sys/dev/sab/sab.c
1.25 +1 -1 src/sys/dev/uart/uart_tty.c
1.33 +1 -1 src/sys/dev/zs/zs.c
1.17 +2 -2 src/sys/netgraph/bluetooth/drivers/bt3c/ng_bt3c_pccard.c
Remove a stray return statement in the interrupt dispatch function
that caused a premature exit after calling a fast interrupt handler
and bypassing a much needed critical_exit() and the scheduling of
the interrupt thread for non-fast handlers. In short: unbreak :-)
Revision Changes Path
1.53 +0 -1 src/sys/ia64/ia64/interrupt.c
If we get a stray interrupt, return after logging it. In the extremely
rare case of a stray interrupt to an unregistered source (such as a stray
interrupt from the 8259As when using APIC), this could result in a page
fault when it tried to walk the list of interrupt handlers to execute
INTR_FAST handlers. This bug was introduced with the intr_event changes,
so it's not present in 5.x or 6.x.
Submitted by: Mark Tinguely tinguely at casselton dot net
Revision Changes Path
1.17 +1 -0 src/sys/amd64/amd64/intr_machdep.c
1.16 +1 -0 src/sys/i386/i386/intr_machdep.c
Approved by: re (scottl)
sys/dev/uart/uart_cpu_sparc64.c 1.20, 1.22
- Add support for using LOM (Lights Out Management) and RSC (Remote System
Control) devices as console.
- Add my copyright to uart_cpu_sparc64.c.
- Recognize the SAB82532 in USIII machines. This is MFC'ed for consistency
as one part of the original commit, sys/dev/uart/uart_bus_ebus.c rev. 1.7,
was already MFC'ed to RELENG_6 (in rev. 1.6.2.2).
Approved by: re (scottl)
work. The code comment describes the issue, basically an as yet not
totally understood interrupt routing problem. This hack is being done
to RELENG_6 so that the hme interface works on E250's for the release,
but is not being done in HEAD so more work on the interrupt routing
issue can be done.
Requested by: marius
Approved by: re (scottl)
sys/dev/uart/uart_cpu_sparc64.c 1.21
- Change the code that determines whether to use a serial console and
which serial device to use in that case respectively to not rely on
the OFW names of the input/output and stdin/stdout devices. 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.
- Adjust the size of some buffers.
- Remove the package handle of the '/options' node from the argument
list of uart_cpu_getdev_dbgport().
Approved by: re (scottl)
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 <[email protected]>, 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
engineering the pending interrupt sources from the current
state of the controller. For channel A we can always read the
interrupt pending register (RR3). For channel B we can read
the interrupt vector register (RR2) because it contains the
modified vector and thus includes the interrupt source.
Since we currently need puc(4) for the Z8530, we know that
the interrupt handler for both channels will be called and
thus that RR3 will always be read at least once, even if ch A
has no pending interrupt.
NOTE: The modified interrupt vector has no value that represent
a lack of pending interrupt for channel B. That is, the
value read when no interrupts are pending is the same as the
value for the special receive condition. Fortunately, we don't
actually have to depend on that interrupt source. This does
mean that we need to properly handle the overflow condition,
when we read received character from the chip.
o The DSR signal is represented by the SYNC bit in the external
status register (RR0). We now properly track DSR.
o It's save to enable the external/status interrupt source. We
now get interrupts when line signals (DSR, DCD or CTS) change.
Problems fixes:
o interrupt storms.
o blocked open(2).
o lack of (hardware) flow control.
o unable to report DSR.
MFC after: 5 days
the address of a channel on a SCC, it returns 0 on failure. [1]
- Hardcode channel 1 for the keyboard on Z8530, the information present
in the Open Firmware device tree doesn't allow to determine this via
uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5
of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to
avoid the hang that revision works around) and consequently syscons(4)
on Ultra 2 work. There's a problem with the keyboard LEDs similar to
the one on Ultra 60 (LEDs don't get lit under X) though, instead of
lighting just a specific single one all get lit and can't be turned off
again. [1]
- Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard()
do and their constraints.
- Improve the comments about what uart_cpu_getdev_[console,dbgport]() do,
they don't return an address (as in bus) but an Open Firmware package
handle.
Reviewed by: marcel (modulo the comments) [1]
- The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c
etc. that UARTs are the only relevant ISA devices on sparc64 turned out
to be false. While there are sparc64 models where UARTs are the only
devices on the ISA bus there are in fact also low-cost models where all
devices traditionally found on the EBus are hooked up to the ISA bus.
There are also models that use a mix between EBus and ISA devices with
things like an AT keyboard controller and other rather interesting
devices that we might want to support in the futute hook up to the ISA
bus.
In order to not need to add sparc64 specific device_identify methods to
all of the respective ISA drivers and also not add OFW specific code to
the common ISA code make the sparc64 ISA bus code fake up PnP devices so
most ISA drivers probe their devices without further changes.
Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE
1275-1994 for the properties of most of the ISA devices which would
allow to obtain the vendor and logical IDs from their properties. So we
we just use a simple table which maps the name properties to PnP IDs.
This could be done in a more sophisticated way but I courrently don't
see the need for this. [1]
- Add the children with fully mapped and specified resources (in the OFW
sense) similar to what is done in the EBus code for the IRQ resources
of the children as adjusting the resources and the resource list entries
respectively in isa_alloc_resource() as done perviously causes trouble
with drivers which use rman_get_start(), pass-through or allocate and
release resources multiple times, etc.
Adjusting the resources might be better off in a bus_activate_resource
method but the common ISA code currently doesn't allow for an
isa_activate_resource(). [2]
With this change:
- ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires
real ISADMA code but it currently only consists of stubs on sparc64).
- atkbdc(4) and atkbdc(4) attach, no further testing done.
- fdc(4) itself attaches but causes a hang while attaching fd0 also
when is DMA disabled, further work in fdc(4) is required here as e.g.
fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports
more than one floppy drive at all).
All of these drivers previously caused panics in the sparc64 ISA code.
- Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and
declare one global variable which isn't used outside of isa.c static.
o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile:
- Remove the code for registering the UARTs on the ISA bus from the
sparc64 uart_cpu_identify() again and rely on probing them via PnP.
Original idea by: tmm [1]
No objections by: tmm [1], [2]
current baudrate setting. Use this ioctl() when we don't know the
baudrate of the sysdev (as represented by a 0 value). When the
ioctl() fails, e.g. when the backend hasn't implemented it or the
hardware doesn't provide the means to determine its current baudrate
setting, we invalidate the baudrate setting by setting it to -1.
None of the backends currently implement the new ioctl().
A baudrate we consider insane is silently replaced with 0. When the
baudrate is 0, we will not try to program the hardware. Instead we
leave the communication speed unaltered, maximizing the chance to
have a working console. Obviously this means we allow specifying a
0 baudrate for exactly that purpose.
Marius Strobl