Serial Driver and Console - Revision history

John bougs: /* Writing the real serial driver */

2006-06-16T19:17:20Z

‎Writing the real serial driver

John bougs: /* Writing the real serial driver */

2006-06-16T19:16:38Z

‎Writing the real serial driver

John bougs: /* Writing the real serial driver */

2006-06-16T19:15:44Z

‎Writing the real serial driver

Alec v: "serial drivers" article

2005-09-06T14:30:43Z

"serial drivers" article

Alec v: format

2005-07-31T22:00:05Z

format

Alec v: link

2005-07-31T21:46:47Z

link

Ralf at 14:45, 30 June 2005

2005-06-30T14:45:19Z

Alec v: Consoles in general

2005-06-12T17:33:51Z

Consoles in general

ThomasPetazzoni: Writing the real serial driver

2004-11-09T17:33:57Z

Writing the real serial driver

ThomasPetazzoni: Minor corrections

2004-11-09T13:11:36Z

Minor corrections

@@ Line 99: / Line 99: @@
 ==== Writing the real serial driver ====
-The code and informations of this section are based on a Linux Journal article The Serial Driver Layer
+The code and informations of this section are based on a Linux Journal article "The Serial Driver Layer"
 by Greg Kroah-Hartman, which is available online at http://www.linuxjournal.com/article/6331. The code of the article, a Tiny TTY driver is available at http://www.ibiblio.org/pub/linux/docs/linux-journal/listings/issue104/6331l1.txt

@@ Line 100: / Line 100: @@
 The code and informations of this section are based on a Linux Journal article The Serial Driver Layer
-by Greg Kroah-Hartman, which is available online at [http://www.linuxjournal.com/article/6331]. The code of the article, a Tiny TTY driver is available at http://www.ibiblio.org/pub/linux/docs/linux-journal/listings/issue104/6331l1.txt
+by Greg Kroah-Hartman, which is available online at http://www.linuxjournal.com/article/6331. The code of the article, a Tiny TTY driver is available at http://www.ibiblio.org/pub/linux/docs/linux-journal/listings/issue104/6331l1.txt
 Now, you want to use /dev/ttySx devices, for example to run shells on your platform. You need a real serial driver. Let's create the file <code>drivers/serial/foo.c</code>

@@ Line 99: / Line 99: @@
 ==== Writing the real serial driver ====
-The code and informations of this section are based on a Linux Journal article, which is not available online anymore. The code of the article, a Tiny TTY driver is available at http://www.ibiblio.org/pub/linux/docs/linux-journal/listings/issue104/6331l1.txt
+The code and informations of this section are based on a Linux Journal article The Serial Driver Layer
 Now, you want to use /dev/ttySx devices, for example to run shells on your platform. You need a real serial driver. Let's create the file <code>drivers/serial/foo.c</code>

@@ Line 96: / Line 96: @@
   console_initcall(mv64340_console_init);
 ==== Writing the real serial driver ====
@@ Line 149: / Line 148: @@
 == See also ==
 * [[Serial Cable]]

@@ Line 26: / Line 26: @@
 ; line : Only used for run-time serial configuration. It is the index into the 'rs_table[] array'.
-; io_type : io_type determines how your serial registers are accessed. Two common types are SERIAL_IO_PORT and SERIAL_IO_MEM. A SERIAL_IO_PORT type driver uses the inb/outb macros to access registers whose base address is at port. In other words, if you specify SERIAL_IO_PORT as the io_type, you should also specify the port parameter.
+; io_type : io_type determines how your serial registers are accessed. Two common types are SERIAL_IO_PORT and SERIAL_IO_MEM.<br>A SERIAL_IO_PORT type driver uses the inb/outb macros to access registers whose base address is at port. In other words, if you specify SERIAL_IO_PORT as the io_type, you should also specify the port parameter.<br>For SERIAL_IO_MEM, the driver uses readb/writeb macros to access regsiters whose address is at iomem_base plus a shifted offset. The number of digits shifted is specified by iomem_reg_shift. For example, all the serial registers are placed at 4-byte boundary, then you have an iomem_reg_shift of 2.
 For SERIAL_IO_MEM, the driver uses readb/writeb macros to access regsiters whose address is at iomem_base plus a shifted offset. The number of digits shifted is specified by iomem_reg_shift. For example, all the serial registers are placed at 4-byte boundary, then you have an iomem_reg_shift
 of 2.
 Generally SERIAL_IO_PORT is for serial ports on an ISA bus and SERIAL_IO_MEM is for memory-mapped serial ports. There are also SERIAL_IO_HUB6 and SERIAL_IO_GSC. The HUB6 was a multi-port serial card produced by Bell Technologies. The GSC is a special bus found on PA-RISC systems. These options will not be used on any MIPS boards.

@@ Line 18: / Line 18: @@
 * Reserve the 'rs_table[]' size, see the 'drivers/char/serial.c' file. Unfortunately there is not a clean way to accomplish this yet. A temporary workaround is to define CONFIG_SERIAL_MANY_PORTS in 'arch/mips/config-shared.in' for your board. This configuration reserves up to 64 serial port entries for your board!
-* Call the 'early_serial_setup()' routine in your board setup routine. Here is a piece of sample run-time initialization code.
+* Call the 'early_serial_setup()' routine in your board setup routine. Here is a [http://linux.junsun.net/porting-howto/src/vr4181_serial_init.c piece of sample run-time initialization code].
 == Serial parameters ==

← Older revision		Revision as of 14:45, 30 June 2005
Line 149:		Line 149:

	Next page: [[KGDB]]		Next page: [[KGDB]]
		+
		+	== See also ==
		+	* [[Serial Cable]]

@@ Line 97: / Line 97: @@
 And make sure this function gets called during initialization :
   console_initcall(mv64340_console_init);
 ==== Writing the real serial driver ====
@@ Line 144: / Line 146: @@
 When a character is received by the serial device, an interrupt is issued. The corresponding interrupt handler has to forward the characters to the //serial_core// infrastructure. The <code>foo_stop_rx</code> function is not used in the reception process.
 Next page: [[KGDB]]

← Older revision		Revision as of 17:33, 9 November 2004
Line 103:		Line 103:

	Now, you want to use /dev/ttySx devices, for example to run shells on your platform. You need a real serial driver. Let's create the file <code>drivers/serial/foo.c</code>		Now, you want to use /dev/ttySx devices, for example to run shells on your platform. You need a real serial driver. Let's create the file <code>drivers/serial/foo.c</code>
		+
		+	To implement a driver using the //serial_core// architecture, we need to implement several functions, which are listed in the <code>uart_ops</code> structure, so you can start by defining such a structure :
		+
		+	static struct uart_ops foo_ops = {
		+	.tx_empty = foo_tx_empty,
		+	.set_mctrl = foo_set_mctrl,
		+	.get_mctrl = foo_get_mctrl,
		+	.stop_tx = foo_stop_tx,
		+	.start_tx = foo_start_tx,
		+	.stop_rx = foo_stop_rx,
		+	.enable_ms = foo_enable_ms,
		+	.break_ctl = foo_break_ctl,
		+	.startup = foo_startup,
		+	.shutdown = foo_shutdown,
		+	.type = foo_type,
		+	.release_port = foo_release_port,
		+	.request_port = foo_request_port,
		+	.config_port = foo_config_port,
		+	.verify_port = foo_verify_port,
		+	.set_termios = foo_set_termios,
		+	};
		+
		+	There is quite a lot of functions that you have to implement if you want all functionnalities. But if you only want a simple serial console, only a subset of them is really needed. Let's define empty functions for the one that are useless :
		+
		+	static unsigned int foo_tx_empty(struct uart_port *port) { return 0; }
		+	static void foo_set_mctrl(struct uart_port *port, unsigned int mctrl) { }
		+	static unsigned int foo_get_mctrl(struct uart_port *port) { return 0; }
		+	static void foo_break_ctl(struct uart_port *port, int break_state) { }
		+	static void foo_enable_ms(struct uart_port *port) { }
		+	static void foo_release_port(struct uart_port *port) { }
		+	static int foo_request_port(struct uart_port *port) { return 0; }
		+	static void foo_config_port(struct uart_port *port, int flags) { }
		+	static int foo_verify_port(struct uart_port port, struct serial_struct ser) { return 0; }
		+	static void foo_set_termios(struct uart_port port, struct termios new,
		+	struct termios *old) { }
		+
		+	We still have to implement <code>foo_type</code>, <code>foo_start_tx</code>, <code>foo_stop_tx</code>, <code>foo_stop_rx</code>, <code>foo_startup</code> and <code>foo_shutdown</code>. You might wonder why you don't see any //write//, //read//, //input// or //output// function. This is because the //serial_core// infrastructure rely on interrupts.
		+
		+	To transmit data, the //serial_core// infrastructure calls <code>foo_start_tx</code>, which should enable transmission on the serial port. As there's nothing to transmit, the serial port will issue an interrupt that acknowledge the end of a transmission. In the interrupt handler, you can now fetch the data to be sent, and send them to the serial port. If there is a lot of data, you won't be able to send it at once. So, you will wait the next interrupt that acknowledge the end of a transmission to send more data. During this process, you inform the //serial_core// infrastructure how many bytes have already been sent. When //serial_core// is happy with what you did, it will call <code>foo_stop_tx</code> to stop transmission.
		+
		+	When a character is received by the serial device, an interrupt is issued. The corresponding interrupt handler has to forward the characters to the //serial_core// infrastructure. The <code>foo_stop_rx</code> function is not used in the reception process.

	Next page: [[KGDB]]		Next page: [[KGDB]]

@@ Line 44: / Line 44: @@
 === The drivers/serial way ===
-In Linux&nbsp;2.6there is an other, even simpler alternative to the generic serial way described above. In fact, Linux&nbsp;2.6 deprecates serial drivers in drivers/char and the only ones still left there are old drivers that haven't been rewritten yet.  The new way of doing things is using the drivers/serial/serial_core.c infrastructure, which allows to write a very simple serial driver.
+In Linux&nbsp;2.6 there is an other, even simpler alternative to the generic serial way described above. In fact, Linux&nbsp;2.6 deprecates serial drivers in drivers/char and the only ones still left there are old drivers that haven't been rewritten yet.  The new way of doing things is using the drivers/serial/serial_core.c infrastructure, which allows to write a very simple serial driver.
 ==== Writing the kernel console driver ====
@@ Line 62: / Line 62: @@
 - <code>static void foo_console_write(struct console *co, const char *s, unsigned count)</code>, which should write the <code>count</code> characters from the string <code>s</code> to the serial port. For example, it can simply loop on each character of the string and call an internal function which aims at writing a single character to the serial port. With most chipsets, outputting a character is simply a matter of writing the ASCII value of this character to a specific hardware register, and then wait for a busy bit to clear in another register before leaving the function. It is recommended to use polling here instead of interrupts.
-- <code>static __init int mv64340_console_setup(struct console *co, char *options)</code>, which should initialize the serial port hardware according to the given <code>options</code>. If your serial hardware is already initialized by the [[Firmware]], then you don't need to do anything in this function.
+- <code>static __init int foo_console_setup(struct console *co, char *options)</code>, which should initialize the serial port hardware according to the given <code>options</code>. If your serial hardware is already initialized by the [[Firmware]], then you don't need to do anything in this function.
 Now, write a simple structure that describes the kernel console :