[PATCH] serial: Comment typo fix for include/linux/serial_reg.h

Fix typo and cut-n-paste error in serial_reg.h comments for 16C950 ACR.

Signed-off-by: Michał Mirosław <mirq-serial <at> rere.qmqm.pl>
---

diff -urN linux-2.6.16-rc1-mq12/include/linux/serial_reg.h linux-2.6.16-rc1-mq123/include/linux/serial_reg.h
--- linux-2.6.16-rc1-mq12/include/linux/serial_reg.h	2006-01-03 04:21:10.000000000 +0100
+++ linux-2.6.16-rc1-mq123/include/linux/serial_reg.h	2006-01-22 00:29:50.458495618 +0100
 <at>  <at>  -247,10 +247,10  <at>  <at> 
 #define UART_CTR	0xFF

 /*
- * The 16C950 Additional Control Reigster
+ * The 16C950 Additional Control Register
  */
 #define UART_ACR_RXDIS	0x01	/* Receiver disable */
-#define UART_ACR_TXDIS	0x02	/* Receiver disable */
+#define UART_ACR_TXDIS	0x02	/* Transmitter disable */
 #define UART_ACR_DSRFC	0x04	/* DSR Flow Control */
 #define UART_ACR_TLENB	0x20	/* 950 trigger levels enable */
 #define UART_ACR_ICRRD	0x40	/* ICR Read enable */
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix compile error in 8250_au1x00.c

This patch fixes a compile error when building the 8250_au1x00 driver
for the DB1550, which doesn't have a UART2 defined, resulting in a 
compile error.

There are additional rumors of strangeness on the DB1550, but those
are unsubstantiated at this point.  At least with this patch, it will
compile.

Jordan
-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

[PATCH]:  Fixup for the AU1X00 8250 driver

The DB1550 actually doesn't have a UART2.  Remove it from the list.

Signed-off-by: Jordan Crouse <jordan.crouse <at> amd.com>
---

 drivers/serial/8250_au1x00.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/8250_au1x00.c b/drivers/serial/8250_au1x00.c
index 06ae8fb..8d8d7a7 100644
--- a/drivers/serial/8250_au1x00.c
+++ b/drivers/serial/8250_au1x00.c

Re: [PATCH] Fix compile error in 8250_au1x00.c

On Tue, Feb 07, 2006 at 02:15:00PM -0700, Jordan Crouse wrote:
> The DB1550 actually doesn't have a UART2.  Remove it from the list.

Applied, thanks.

--

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Small time UART configuration fix for AU1100 processor

Hi,

The AU1100 processor does not have an internal UART2. Only UART0,
UART1 and UART3 exist. This patch removes the non existing UART2
and replaces it with a descriptive comment.

-- 
$ cat ~/.signature
Freddy Spierenburg <freddy <at> dusktilldawn.nl> http://snarl.nl/~freddy/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1  E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!

diff -Naur master.orig/drivers/serial/8250_au1x00.c master.good/drivers/serial/8250_au1x00.c
--- master.orig/drivers/serial/8250_au1x00.c	2006-02-17 10:57:28.000000000 +0000
+++ master.good/drivers/serial/8250_au1x00.c	2006-02-17 14:02:38.000000000 +0000
 <at>  <at>  -51,7 +51,7  <at>  <at> 
 #elif defined(CONFIG_SOC_AU1100)
 	PORT(UART0_ADDR, AU1100_UART0_INT),
 	PORT(UART1_ADDR, AU1100_UART1_INT),
-	PORT(UART2_ADDR, AU1100_UART2_INT),
+	/* The internal UART2 does not exist on the AU1100 processor. */
 	PORT(UART3_ADDR, AU1100_UART3_INT),
 #elif defined(CONFIG_SOC_AU1550)
 	PORT(UART0_ADDR, AU1550_UART0_INT),

[PATCH] serial: remove 8250_acpi (replaced by 8250_pnp and PNPACPI)

[This is post-2.6.16 material]

With the combination of PNPACPI and 8250_pnp, we no longer need 8250_acpi.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas <at> hp.com>

Index: work-mm4/drivers/serial/Kconfig
===================================================================
--- work-mm4.orig/drivers/serial/Kconfig	2006-03-01 15:37:42.000000000 -0700
+++ work-mm4/drivers/serial/Kconfig	2006-03-01 15:38:09.000000000 -0700
 <at>  <at>  -77,14 +77,6  <at>  <at> 

 	  If unsure, say N.

-config SERIAL_8250_ACPI
-	bool "8250/16550 device discovery via ACPI namespace"
-	default y if IA64
-	depends on ACPI && SERIAL_8250
-	---help---
-	  If you wish to enable serial port discovery via the ACPI
-	  namespace, say Y here.  If unsure, say N.
-
 config SERIAL_8250_NR_UARTS
 	int "Maximum number of 8250/16550 serial ports"
 	depends on SERIAL_8250
Index: work-mm4/drivers/serial/Makefile
===================================================================
--- work-mm4.orig/drivers/serial/Makefile	2006-03-01 15:37:42.000000000 -0700
+++ work-mm4/drivers/serial/Makefile	2006-03-01 15:38:09.000000000 -0700
 <at>  <at>  -5,7 +5,6  <at>  <at> 

Re: [PATCH] Fix compile error in 8250_au1x00.c

On Tue, 7 Feb 2006, Jordan Crouse wrote:

> There are additional rumors of strangeness on the DB1550, but those
> are unsubstantiated at this point.  At least with this patch, it will
> compile.

I can confirm strangeness on Au1550, and I've pinned it down to wrong 
way of setting the divisor register. The alchemy uart have got a spearate 
register for divisor, while the driver tries to set the divisor latch 
just like on any 16550 uart.

How would be a good way of solving this? I can imagine a couple of ways:

1. Make divisor latch read/write a bit more abstract, so that a 
alternative function can be used for alchemy.

2. Add divisor latch to the alchemy uart register map. But since the 
divisor register is located in a single 32-bit register and the driver 
will try to access it one byte at a time; byte access would be needed. And 
this would add some endian handling...

--

-- 
Jon Anders Haugum

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] serial8250: set divisor register correctly for AMD Alchemy SoC uart

Alchemy SoC uart have got a non-standard divisor register that needs some 
special handling.

This patch adds divisor read/write functions with test and special 
handling for Alchemy internal uart.

Signed-off-by: Jon Anders Haugum <jonah <at> omegav.ntnu.no>

---

--- linux-2.6.16-rc5/drivers/serial/8250.c.orig	2006-03-03 02:12:10.000000000 +0100
+++ linux-2.6.16-rc5/drivers/serial/8250.c	2006-03-03 02:16:19.000000000 +0100
 <at>  <at>  -362,6 +362,40  <at>  <at>  serial_out(struct uart_8250_port *up, in
  #define serial_inp(up, offset)		serial_in(up, offset)
  #define serial_outp(up, offset, value)	serial_out(up, offset, value)

+/* Uart divisor latch read */
+static inline int _serial_dl_read(struct uart_8250_port *up)
+{
+	return serial_inp(up, UART_DLL) | serial_inp(up, UART_DLM) << 8;
+}
+
+/* Uart divisor latch write */
+static inline void _serial_dl_write(struct uart_8250_port *up, int value)
+{
+	serial_outp(up, UART_DLL, value & 0xff);
+	serial_outp(up, UART_DLM, value >> 8 & 0xff);
+}
+
+#ifdef CONFIG_SERIAL_8250_AU1X00

Possible bug in serial driver 8250/8250-fourport

Hello,

I am writing to this list because i am now clueless on a problem i am having 
with writing data on a serial port, and now the only thing i can think of is 
a serial driver bug.
The situation is the following :
I have a NetMos Technology PCI 9845 Multi-I/O Controller (rev 01), which has 
four ports. Each of its ports are connected as follow :
- port 1 TX connected to a Midi Chipset DREAM SAM9708 port 1
  port 1 RX connected to FATAR midi keyboard 
- port 2 TX connected to a Midi Chipset DREAM SAM9708 port 2
- port 3 connected to an external midi in/out (1)
- port 4 connected to an external midi in/out (2)

This configuration has been tested on both kernel 2.6.10 with 8250 module, and 
2.6.15 with 8250-fourport module, the problem arises on both.
Each of the serial ports are configured this way :
setserial /dev/tts/$id uart 16550A port 0x$addr irq $irq
^fourport spd_cust divisor 8 low_latency

The problem is as follow :
When playing MIDI data over port 1, sometimes the output just stops, the data 
doesn't go anymore to the Dream 1 port. Then (and that's the strange part), 
if we press a key of the FATAR keyboard (connected to the same serial port 
but on RX), all the data that was not played comes out all of a sudden, and 
the playback continues to be output normally. This problem does *NOT* happen 
on any of the other serial ports, only on the one where TX is connected to 
the dream 1 and RX to the FATAR midi keyboard.
I have been trying with both snd-serialmidi alsa driver, as well with a 
homemade user-land program which drives midi events to the serial port, and 

Re: Possible bug in serial driver 8250/8250-fourport

Did you try monitoring /proc/tty/driver/serial for the ports in question
(byte counts in and out, and any errors (framing, parity, etc)) are in
there, you can confirm your setserial settings there too, account for all
bytes in and out.

Also -- do you have software or hardware flow control going?
i.e. how are your tty's configured?  sounds like they should be a 
raw setup -- if canonical mode or otherwise are consuming characters
that should normally pass through to your equipment it may cause
problems.  I have no clue what protocol your music equipment speaks.

Might be worthwhile sending your code snippet that configures your ttys
and if hardware flow control is involved etc.

The serial and tty layer (I've found) have been very robust for a bunch
of multiport stuff I've been doing in the last 6 months (albeit a 2.4
kernel).  The tty stuff really has to work right as a lot of stuff
besides just serial ports are tty based (duh).

Good luck w/ your project.

> Hello,
> 
> I am writing to this list because i am now clueless on a problem i am having 
> with writing data on a serial port, and now the only thing i can think of is 
> a serial driver bug.
> The situation is the following :
> I have a NetMos Technology PCI 9845 Multi-I/O Controller (rev 01), which has 
> four ports. Each of its ports are connected as follow :
> - port 1 TX connected to a Midi Chipset DREAM SAM9708 port 1