Serial: updated serial drivers
Hi,
I've been maintaining a serial driver "off the side" of the ARM port which cleans up the serial driver mess that we currently have, with many duplications of serial.c, each with subtle bugs.
Since ARM seems to have a poliferation of various UARTs, each of them different, if this were to carry on we'd end up with 6 or 7 more copies of serial.c. This is obviously unacceptable.
So, with a view to cutting down on this duplication, I split serial.c into a core driver, which can be used by various "low level" serial hardware drivers, including the ARM ones, but also the 8250/16550 drivers.
Jeff and Arjan (iirc) expressed some concern about the PCI and PNP code in serial.c, so that got separated out in what has now come to be known as the serial rewrite.
The only non-ARM driver this patch affects is the 8250/16550 serial.c driver. The others have not been ported to this infrastructure yet.
The patch does contain details on the interface between the low level and core serial drivers.
This project was first announced to linux-kernel on 6 November 2001:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100504194616062&w=2
Linus has expressed an interest in merging this work; hence this message. Before I do send it to Linus, I would like to get some feedback on the code. So, here is the latest patch against 2.5.24:
http://www.home.arm.linux.org.uk/cvs/serial-2.5.24.diff.bz2
It should cleanly apply to 2.5.24. The names of the serial options have changed, so use your favourite configuration program to select the relevant options.
This patch affects the following mainline drivers:
- 8250/16550 "generic" serial driver (serial.o)
- PCMCIA serial probe module (serial_cs.o)
Please send any bug reports in my direction. There is one specific area that I'm unable to test here - 8250/16x50 "shared" interrupts (where multiple 8250/16x50 devices share the same interrupt line). I'm expecting my mailbox to overflow tomorrow, so...
Note that, as ever, 8250/16x50 sharing with non-serial devices is NOT guaranteed to work on edge-based IRQ systems like PCs (and if you want this to work you can either configure your kernel appropriately, or pass "share_irqs=1" in modules.conf for serial_8250.o)
The future:
- work with tytso to integrate any relevant bits of serial_core.c with the tty layer.
- fix bugs
- there seems to be a fair number of people wanting support for the higher speeds of UARTs (eg 16C950 and most motherboard devices)
- add support for driverfs
- remove the silly situation where we have ports openable, but no hardware behind them (and use some other method to create serial devices on demand if still required)
- remove callout functionality, which has been marked as such for a few years now. tytso mentions that the only program this might break is minicom, which should be fixed.
I'm sure there's other stuff people want. 8)
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
In article <[email protected]>,
Quoted 3 lines · Russell King
- remove callout functionality, which has been marked as such for a few years now. tytso mentions that the only program this might break is minicom, which should be fixed.
Minicom doesn't care which port you use. It might be that some people have saved configs of 6 years old that still contain references to a cua device, but that's a problem any serial program has.
Quoted 1 line
From the manpage of any recent minicom:
Serial port setup
*A - Serial device
/dev/tty1 or /dev/ttyS1 for most people.
/dev/cua<n> is still possible under linux, but not recommended any more because these devices are obsolete and many newly installed systems with kernel 2.2.x don't have them. Use /dev/ttyS<n> instead.
Mike.
Quoted 3 lines · Russell King
I've been maintaining a serial driver "off the side" of the ARM port which cleans up the serial driver mess that we currently have, with many duplications of
serial.c, each with subtle bugs.
global_cli() overhead on my testbox is a significant problem.
Profile info from tbench 1024 with ttyS0 as stdout, taken on a 16 cpu i386 box with 16GB of RAM and irqbalance disabled, (needed to boot):
90372662 total 713.6412 44801051 default_idle 861558.6731 36220921 mod_timer 113190.3781 2510075 timer_bh 2764.3998 2344795 __global_cli 8620.5699 1446315 __wake_up 7693.1649 1370742 do_gettimeofday 10078.9853 924996 schedule 831.8309 512368 do_softirq 2328.9455 103136 tasklet_hi_action 526.2041 40640 system_call 923.6364 19238 do_page_fault 14.2927 12835 add_wait_queue 103.5081 10667 remove_wait_queue 83.3359 7990 bh_action 38.4135 5303 pte_alloc_one 27.6198 4665 schedule_timeout 29.1562 4584 pgd_alloc 24.3830
3870 syscall_call 351.8182
3633 try_to_wake_up 6.3073
3100 exit_notify 3.5068
2566 del_timer 14.9186
The disabling of irqbalance should make these profiling results valid.
Cheers,
Bill
Quoted 3 lines · Russell King
Quoted 3 lines
I've been maintaining a serial driver "off the side" of the ARM port which cleans up the serial driver mess that we currently have, with many duplications of
serial.c, each with subtle bugs.
Quoted 3 lines · William Lee Irwin III
global_cli()overhead on my testbox is a significant problem. Profile info from tbench 1024 with ttyS0 as stdout, taken on a 16 cpu i386 box with 16GB of RAM and irqbalance disabled, (needed to boot):
the profiling results were for a kernel without the new serial stuff. The new serial stuff appears to need some arch compatibility auditing/ fixes for NUMA-Q.
Cheers,
Bill
Quoted 3 lines · William Lee Irwin III
the profiling results were for a kernel without the new serial stuff. The new serial stuff appears to need some arch compatibility auditing/ fixes for NUMA-Q.
I am not aware of any architecture specific code in the new serial code, with the exception of a couple of writes to port 0x80 for i386 architectures (which the original serial.c driver did as well.)
Can you give an idea where it fails/kernel messages please?
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 3 lines · William Lee Irwin III
Quoted 3 lines
the profiling results were for a kernel without the new serial stuff. The new serial stuff appears to need some arch compatibility auditing/ fixes for NUMA-Q.
Quoted 4 lines · Russell King
I am not aware of any architecture specific code in the new serial code, with the exception of a couple of writes to port
0x80for i386 architectures (which the originalserial.cdriver did as well.) Can you give an idea where it fails/kernel messages please?
It's not obvious to me, either, I actually read the stuff and didn't see where the problem could be.
It appeared to fail before console_init(). The system is largely dedicated to other projects so there will be a bit of turnaround time between test runs. I'll probably be able to pinpoint the point of failure later tonight.
Cheers,
Bill
Quoted 7 lines · William Lee Irwin III
Quoted 3 lines · Russell King
I've been maintaining a serial driver "off the side" of the ARM port which cleans up the serial driver mess that we currently have, with many duplications of
serial.c, each with subtle bugs.
Quoted 5 lines
global_cli()overhead on my testbox is a significant problem.Profile info from tbench 1024 with ttyS0 as stdout, taken on a 16 cpu i386 box with 16GB of RAM and irqbalance disabled, (needed to boot):
<snip profile>
Quoted 2 lines
The disabling of irqbalance should make these profiling results valid.
So, is irqbalance the thing that is screwing up our profiles on 2.5? We were getting some strage profiles that made us look at oprofile again.
oprofile is really cool, but readprofile is dead simple.
Signature · 2 lines
Dave Hansen [email protected]