src-test2/sys/dev/uart, branch release/10.0.0

A final test with unmodified code has shown that a delay of 150ms

2013-08-30T15:26:45Z

is not giving us a 100% success rate. Bump the delay to 200ms as that seems to do the trick. Note that during testing the delay was added to uart_bus_attach() in uart_core.c. While having the delay in a different place can change the behaviour, it was not expected. Having to bump the delay with another 50ms could therefore be an indication that the problem can not be solved with delays. Reported by: kevlo@ Tested by: kevlo@

Work-around a timing problem with the ITE IT8513E now that the core

2013-08-29T16:26:04Z

calls ns8250_bus_ipend() almost immediately after ns8250_bus_attach(). As it appears, a line break condition is being signalled for almost all received characters due to this. A delay of 150ms seems enough to allow the H/W to settle and to avoid the problem. More analysis is needed, but for now a regression has been addressed. Reported by: kevlo@ Tested by: kevlo@

Add support for uarts other than the serial console in TI OMAP SoCs.

2013-08-21T14:33:02Z

The TI uart hardware is ns16550-compatible, except that before it can be used the clocks and power have to be enabled and a non-standard mode control register has to be set to put the device in uart mode (as opposed to irDa or other serial protocols). This adds the extra code in an extension to the standard ns8250 probe routine, and the rest of the driver is just the standard ns8250 code.

Make the uart ns8250 high-level interface public rather than static.

2013-08-21T14:26:15Z

This makes it easier to implement new drivers which are "mostly ns8250" but with some small difference such as needing to enable clocks or poke a non-standard register at probe or attach time.

Use an if/else sequence rather than unrelated if statements, so that a

2013-08-21T04:08:58Z

device compatible with multiple drivers matches the more specific driver first and doesn't overwrite it later with the more generic. Move the generic ns16550 to the end of the list.

Check for generic ns16550 after all other types. A device may be compatible

2013-08-21T04:05:06Z

with 16550 but also have a more specific/capable driver earlier in the list.

Allow UART_POLL_FREQ to be set as a kernel option as well as via tunable

2013-08-19T15:51:30Z

(the code was already set up for this, just needs to be in conf/options). Also, if reporting that polling is being used, report the frequency too.

Set the device description after we call uart_probe(). In uart_probe()

2013-07-25T16:57:27Z

we call device-specific probe functions, which can (and typically will) set the device description based on low-level device probe information. In the end we never actually used the device description that we so carefully maintained in the PCI match table. By setting the device description after we call uart_probe(), we'll print the more user- friendly description by default.

Protect against broken hardware. In this particular case, protect against

2013-07-10T17:42:20Z

H/W not de-asserting the interrupt at all. On x86, and because of the following conditions, this results in a hard hang with interrupts disabled: 1. The uart(4) driver uses a spin lock to protect against concurrent access to the H/W. Spin locks disable and restore interrupts. 2. Restoring the interrupt on x86 always writes the flags register. Even if we're restoring the interrupt from disabled to disabled. 3. The x86 CPU has a short window in which interrupts are enabled when the flags register is written. 4. The uart(4) driver registers a fast interrupt by default. To catch this case, we first try to clear any pending H/W interrupts and in particular, before setting up the interrupt. This makes sure the interrupt is masked on the PIC. The interrupt handler now has a limit set on the number of iterations it'll go through to clear interrupt conditions. If the limit is hit, the handler will return FILTER_SCHEDULE_THREAD. The attach function will check for this return code and avoid setting up the interrupt and foce polling in that case. Obtained from: Juniper Networks, Inc.

Teach UART to attach Exynos/s3/s5 class driver.

2013-06-29T23:48:08Z

Submitted by: Ruslan Bukin Reviewed by: gonzo