summaryrefslogtreecommitdiff
path: root/sys/dev/uart
Commit message (Collapse)AuthorAgeFilesLines
* MFC: sys/conf/files.sparc64 1.83; sys/conf/options.sparc64 1.24;Marius Strobl2007-09-302-86/+385
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Notes: svn path=/stable/6/; revision=172395
* MFC rev 1.21: match all system-devices; don't stop after the first match.Marcel Moolenaar2007-05-011-1/+1
| | | | Notes: svn path=/stable/6/; revision=169183
* MFC rev. 1.10: Add PCI IDs for the HP RMP3 serial port.Marcel Moolenaar2007-04-201-0/+1
| | | | Notes: svn path=/stable/6/; revision=168915
* Partial MFC of rev 1.22 (the other bits were already MFC'd by marcel).Olivier Houchard2007-02-261-22/+12
| | | | | | | | | | 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. Notes: svn path=/stable/6/; revision=167042
* Partial MFC: Remove 16-bit wide I/O. It breaks when the register shiftMarcel Moolenaar2006-11-282-11/+7
| | | | | | | | | | is non-null and may not work on all chipsets. PR: i386/105616 Tested by: Helge Oldach Notes: svn path=/stable/6/; revision=164730
* MFC: Fix our ioctl(2) implementation for ioctls with "int" arguments.Ruslan Ermilov2006-10-041-1/+15
| | | | | | | Approved by: re (hrs, kensmith) Notes: svn path=/stable/6/; revision=162998
* MFC:Maksim Yevmenkin2006-09-251-4/+6
| | | | | | | | | | | 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) Notes: svn path=/stable/6/; revision=162609
* MFC revs 1.7, 1.8 and 1.9:Marcel Moolenaar2006-08-011-30/+67
| | | | | | | | | | | o Add support for non-standard rclk values. o Add Quatech ID o Add 2 NEC IDs o Add 2 HP IDs o Add 5 Timedia IDs Notes: svn path=/stable/6/; revision=160894
* MFC rev. 1.29: Propagate overrun conditions to the TTY layer.Marcel Moolenaar2006-08-011-0/+2
| | | | Notes: svn path=/stable/6/; revision=160890
* MFC: Split struct ithd into struct intr_thread and intr_event andJohn Baldwin2006-03-102-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/stable/6/; revision=156543
* MFC: src/sys/dev/puc/puc_ebus.c 1.6, sys/dev/uart/uart_bus_ebus.c 1.9,Marius Strobl2006-02-152-14/+34
| | | | | | | | | | | | | | | | 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) Notes: svn path=/stable/6/; revision=155710
* Revert the hack introduced in rev. 1.6.2.1, a fix/workaround for theMarius Strobl2006-01-231-15/+0
| | | | | | | | underlying problem was committed in sys/sparc64/pci/psycho.c 1.55 and MFC'ed to RELENG_6 in 1.53.2.1. Notes: svn path=/stable/6/; revision=154725
* MFC: uart_bus_ebus.c:1.8Marcel Moolenaar2005-11-052-4/+2
| | | | | | | | | | uart_core:1.14 Have uart_bus_probe() return BUS_PROBE_DEFAULT when the probe is successful. Notes: svn path=/stable/6/; revision=152099
* MFC rev 1.6: Update PCI IDs.Marcel Moolenaar2005-11-051-10/+15
| | | | Notes: svn path=/stable/6/; revision=152098
* Partial MFC rev 1.11 (diff reduction):Marcel Moolenaar2005-11-051-4/+5
| | | | | | | | | o Style(9) nits o Fix typo in comment o s/-100/BUS_PROBE_GENERIC/ Notes: svn path=/stable/6/; revision=152097
* MFC rev 1.7: Recognize the SAB82532 in USIII machines (marius@)Marcel Moolenaar2005-11-051-1/+1
| | | | Notes: svn path=/stable/6/; revision=152096
* Temporary hack to get the hme network interface on Sun E250 servers toKen Smith2005-10-271-0/+15
| | | | | | | | | | | | | | 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) Notes: svn path=/stable/6/; revision=151769
* MFC: sys/boot/sparc64/loader/metadata.c 1.14,Marius Strobl2005-08-271-21/+21
| | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/stable/6/; revision=149525
* Some chipset drivers redefine the busspace_isa_{io|mem} tags. ThisMarcel Moolenaar2005-06-161-3/+20
| | | | | | | | | | | | | | | | | | | | | | | 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 :-) Notes: svn path=/head/; revision=147423
* Replace the band-aid for allowing to call sunkbd_configure() multipleMarius Strobl2005-06-041-14/+19
| | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=146975
* On AXi and AXmp boards the NS16550 (used to connect keyboard and mouse)Marius Strobl2005-06-041-0/+20
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=146974
* Change the semantics of uart_cpu_getdev_keyboard() to only match SCCs/Marius Strobl2005-06-041-20/+23
| | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=146972
* - Sprinkle some KBD_IS_* and KBD_*_DONE macros in sunkbd_configure() asMarius Strobl2005-05-211-11/+21
| | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=146475
* In uart_cnprobe(), fill in the cn_name field of the consdev structure.Marcel Moolenaar2005-05-081-0/+1
| | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=146013
* Make the Z8530 more reliable as low-level console by making use of theMarcel Moolenaar2005-04-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=145603
* In uart_cpu_getdev_console() when determinig whether we should useMarius Strobl2005-03-121-4/+6
| | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=143468
* - Allocate the interrupt resource as RF_SHAREABLE allowing uart(4) to workMarius Strobl2005-03-021-2/+8
| | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=143025
* - Re-write OF_decode_addr() with a bus-neutral approach, adding supportMarius Strobl2005-02-121-1/+1
| | | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=141753
* Add the keyboard system device before we probe for the keyboard.Marcel Moolenaar2005-01-311-2/+13
| | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=141081
* Fix a logic bug that caused DSR to never be deasserted.Marcel Moolenaar2005-01-301-2/+2
| | | | | | | MFC after: 5 days Notes: svn path=/head/; revision=141069
* o Fix the various interrupt related problems caused by reverseMarcel Moolenaar2005-01-301-31/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=141032
* Start each of the license/copyright comments with /*-, minor shuffle of linesWarner Losh2005-01-0622-21/+22
| | | | Notes: svn path=/head/; revision=139749
* Don't obtain the HCDP address directly from the bootinfo structure.Marcel Moolenaar2004-12-081-3/+5
| | | | | | | Use a function to keep the details at arms length from uart(4). Notes: svn path=/head/; revision=138543
* - Don't blindly use the return value of uart_cpu_channel() to calculateMarius Strobl2004-11-281-7/+33
| | | | | | | | | | | | | | | | | | | | | | | 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] Notes: svn path=/head/; revision=138157
* uart_i8251_ops is gone.Yoshihiro Takahashi2004-11-211-8/+2
| | | | Notes: svn path=/head/; revision=137972
* o Support for the i8251 wasn't there. Remove the files.Marcel Moolenaar2004-11-215-1637/+0
| | | | | | | | o Remove the headers with IC register definitions. The headers are now taken from sys/dev/ic Notes: svn path=/head/; revision=137957
* Include the header with the register definitions from sys/dev/ic. TheyMarcel Moolenaar2004-11-212-2/+4
| | | | | | | are shared now. Notes: svn path=/head/; revision=137956
* Include the common <dev/ic/ns16550.h> instead of the privateMarcel Moolenaar2004-11-201-1/+2
| | | | | | | <dev/uart_dev_ns8250.h>. The latter can be removed now. Notes: svn path=/head/; revision=137949
* Remove the whole uart_cpu_identify() stuff again. Now that it's no longerMarius Strobl2004-11-178-39/+0
| | | | | | | | | | used on sparc64 they are only stubs on all architectures and it doesn't look like if we would need it in the near future again. Ok'ed by: marcel Notes: svn path=/head/; revision=137826
* o sparc64/isa/isa.c:Marius Strobl2004-11-171-40/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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] Notes: svn path=/head/; revision=137819
* Be slightly more paranoid about using the divisor in a division andMarcel Moolenaar2004-11-151-2/+6
| | | | | | | the calculated baudrate. Neither should be 0. Notes: svn path=/head/; revision=137709
* Implement UART_IOCTL_BAUD. Consequently, when the baudrate was unsetMarcel Moolenaar2004-11-141-1/+11
| | | | | | | for the console, we emit the actual baudrate during bus enumeration. Notes: svn path=/head/; revision=137707
* Add UART_IOCTL_BAUD to allow us to query the hardware about theMarcel Moolenaar2004-11-142-0/+6
| | | | | | | | | | | | 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(). Notes: svn path=/head/; revision=137706
* Make sure the baudrate specified with the BR tag is somewhat sane.Marcel Moolenaar2004-11-141-0/+20
| | | | | | | | | | | 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. Notes: svn path=/head/; revision=137704
* Remove asserts which are not correct if the port is a tty.Poul-Henning Kamp2004-10-121-7/+1
| | | | Notes: svn path=/head/; revision=136453
* Use generic tty code instead of (comparatively little) local copies.Poul-Henning Kamp2004-10-122-171/+52
| | | | Notes: svn path=/head/; revision=136421
* Use tty->t_sc to find out softc.Poul-Henning Kamp2004-09-181-8/+6
| | | | Notes: svn path=/head/; revision=135429
* Use ttyalloc() instead of ttymalloc(NULL)Poul-Henning Kamp2004-09-171-1/+1
| | | | Notes: svn path=/head/; revision=135367
* Don't call uart_bus_probe() for non-matching PnP-devices. Trying to probeMarius Strobl2004-08-251-4/+3
| | | | | | | | | | the keyboard controller with uart_bus_probe() caused a hang here on an i386 machine. Approved by: marcel Notes: svn path=/head/; revision=134312
* Fix a style(9) bug (variable definitions inside a nested scope) a patchMarius Strobl2004-08-151-4/+2
| | | | | | | | | | of mine introduced in revision 1.10. Approved by: marcel Prodded by: marcel Notes: svn path=/head/; revision=133738
generated by cgit v1.3 (git 2.53.0) at 2026-04-03 20:45:05 +0000