FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F6.2.0_cvs 2007-01-11T22:54:46Z 2007-01-11T22:54:46Z cvs2svn cvs2svn@FreeBSD.org 2007-01-11T22:54:46Z urn:sha1:201f78d6b90635d961fa373ecd706e3786333b7e 'RELENG_6_2_0_RELEASE'. This commit was manufactured to restore the state of the 6.2-RELEASE image. 2005-04-27T21:57:51Z Marcel Moolenaar marcel@FreeBSD.org 2005-04-27T21:57:51Z urn:sha1:ca83142fc338b492b2e63534cfc55c50a677c2d7 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 2005-01-30T09:00:50Z Marcel Moolenaar marcel@FreeBSD.org 2005-01-30T09:00:50Z urn:sha1:c3c16fcb7b97c93aae946d449540e50ce1e17ae5 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 2005-01-06T01:43:34Z Warner Losh imp@FreeBSD.org 2005-01-06T01:43:34Z urn:sha1:098ca2bda93c701c5331d4e6aace072495b4caaa 2004-11-21T01:43:27Z Marcel Moolenaar marcel@FreeBSD.org 2004-11-21T01:43:27Z urn:sha1:0204ed7a3f2da69e069caf94cd3ab0319858acd8 are shared now. 2004-06-24T10:07:28Z Poul-Henning Kamp phk@FreeBSD.org 2004-06-24T10:07:28Z urn:sha1:28710806cbb64a31d7b4afcba9523376bd0ca941 2004-05-04T06:58:10Z Marcel Moolenaar marcel@FreeBSD.org 2004-05-04T06:58:10Z urn:sha1:eced42860449aef869e5747d341eaa4d6ad29e68 not as a pending interrupt status, but as a matter of status quo. Consequently, when there's no data to be transmitted the condition is not cleared and uart_intr() is stuck in an infinite loop trying to clear the UART_IPEND_TXIDLE status. The z8530_bus_ipend() function is changed to return idle only once after having sent any data. The root cause for this problem is that we cannot use the interrupt status bits of the SCC itself. The register that holds the interrupt status can only be accessed by channel A and holds the status for both channels. Using the interrupt status register would complicate the driver because we need to synchronize access to the SCC between the channels. Elementary testing: marius 2003-09-26T05:14:56Z Marcel Moolenaar marcel@FreeBSD.org 2003-09-26T05:14:56Z urn:sha1:875f70dba4ac5331af98ce31da9e3f02bdf2af21 and the Z8530 drivers used the I/O address as a quick and dirty way to determine which channel they operated on, but formalizing this by introducing iobase is not a solution. How for example would a driver know which channel it controls for a multi-channel UART that only has a single I/O range? Instead, add an explicit field, called chan, to struct uart_bas that holds the channel within a device, or 0 otherwise. The chan field is initialized both by the system device probing (i.e. a system console) or it is passed down to uart_bus_probe() by any of the bus front-ends. As such, it impacts all platforms and bus drivers and makes it a rather large commit. Remove the use of iobase in uart_cpu_eqres() for pc98. It is expected that platforms have the capability to compare tag and handle pairs for equality; as to determine whether two pairs access the same device or not. The use of iobase for pc98 makes it impossible to formalize this and turn it into a real newbus function later. This commit reverts uart_cpu_eqres() for pc98 to an unimplemented function. It has to be reimplemented using only the tag and handle fields in struct uart_bas. Rewrite the SAB82532 and Z8530 drivers to use the chan field in struct uart_bas. Remove the IS_CHANNEL_A and IS_CHANNEL_B macros. We don't need to abstract anything anymore. Discussed with: nyan Tested on: i386, ia64, sparc64 2003-09-23T09:25:38Z Yoshihiro Takahashi nyan@FreeBSD.org 2003-09-23T09:25:38Z urn:sha1:c423dba33446cdad2bea753403c9520ceb9ac488 - Remove buggy uart_cpu_busaddr() function. 2003-09-17T03:11:32Z Marcel Moolenaar marcel@FreeBSD.org 2003-09-17T03:11:32Z urn:sha1:44ed791b92a2d5a5a2ec7dceeaac65e9749a8eda an UART interface could get stuck when a new interrupt condition arose while servicing a previous interrupt. Since an interrupt was already pending, no new interrupt would be triggered. Avoid infinite recursion by flushing the Rx FIFO and marking an overrun condition when we could not move the data from the Rx FIFO to the receive buffer in toto. Failure to flush the Rx FIFO would leave the Rx ready condition pending. Note that the SAB 82532 already did this due to the nature of the chip.