Subject: RFC: run-time defining serial ports

From: Jun Sun <[email-masked]>
Date: Thu, 12 Jul 2001 17:50:33 -0700

As more and more boards are added to Linux-mips tree, many places are getting
crowdier and uglier, including serial.h.  The same thing is true for PPC and
other architectures.

It turns out an easy solution is to let every board sets the serial port
definitions at run-time through calling early_serial_setup() routine.

An easy fix for now is to give a default table size when no serial definition
is given, which at least reserves some slots in the rs_table array.  See the
patch below.

A better solution is probably to provide a config option to define the serial
table size.

A by-product of this arrangement is that you can configure a kernel for
multiple machines.

What do you think?

Jun

diff -Nru include/asm-mips/serial.h.orig include/asm-mips/serial.h
--- include/asm-mips/serial.h.orig      Wed May 16 15:58:29 2001
+++ include/asm-mips/serial.h   Thu Jul 12 17:06:05 2001
@@ -271,3 +271,6 @@
        AU1000_SERIAL_PORT_DEFNS        \
        DDB5477_SERIAL_PORT_DEFNS
 
+#ifnef SERIAL_PORT_DFNS
+#define RS_TABLE_SIZE          4
+#endif

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Jul 2001 13:43:25 +0200

> A better solution is probably to provide a config option to define the serial

It's needed; I have machines here with upto 11 serial interfaces on a lowly
R4700 box; Origins may have _many_ more.

> A by-product of this arrangement is that you can configure a kernel for

  Ralf

---

From: Marc Karasek <[email-masked]>
Date: 13 Jul 2001 10:20:05 -0400

Good idea, I would take it a step further coming at it from a purely
embedded standpoint.  If a option to the kernel could be defined so that
the init code that brings the system up could setup things like the
serial port, etc. and then notify the kernel that the serial port has
been setup with parameters xyz.  All boot monitors (YAMON, PMON,
REDBOOT) initialize the serial port as part of there bootup for use as a
debug monitor, etc.  Why should we have to redo something that is
already taken care of.  Unless there is some case where you want to
reset it, maybe the baud rate is too slow or something.  

I think as linux moves more into the embedded space we will need to deal
with more issues like this.  Where the embedded requirements do not
match with those coming from the desktop/workstation world.  

--
/*************************
Marc Karasek
Sr. Firmware Engineer
iVivity Inc.
[email-masked]
(770) 986-8925
(770) 986-8926 Fax
*************************/

---

From: "Gleb O. Raiko" <[email-masked]>
Date: Fri, 13 Jul 2001 18:48:59 +0400

Marc Karasek wrote:
> 
> All boot monitors (YAMON, PMON,
> already taken care of.

Because we've got completely another policy of handling a device. For
example, a boot monitor (good one) must implement polling technique
only, Linux uses interrupt-driven technique (well, mostly). In general
case, Linux has to reinitialize a device after a boot monitor. It's
clear.

Regards,
Gleb.