[PATCH] Take two of the new serial uart driver.

Hi

The following patch updates the new CPM1/CPM2 uart driver.

Its main features are:

1. The driver is moved on it's own directory within drivers/serial.

2. The defines used on the previous driver are removed and
  the different operations for CPM1/CPM2 are moved to their own
  files.

3. The new DMA api is utilized.

Regards

Pantelis

P.S. Apologies for the bziped patch, but the list limit is too small.

On Thu, 2004-06-03 at 17:13 +0300, Pantelis Antoniou wrote:

The following patch updates the new CPM1/CPM2 uart driver.

Its main features are:

Works for me on WindRiver PowerQUICC II once I make it build:

--- cpm_uart_cpm2.c~	2004-06-03 16:50:03.841824208 +0100
+++ cpm_uart_cpm2.c	2004-06-03 16:55:58.019980944 +0100

@@ -47,7 +47,7 @@

 /**************************************************************/

-void cpm_line_cr_cmd(int line)
+void cpm_line_cr_cmd(int line, int cmd)
 {
 	volatile cpm_cpm2_t *cp = cpmp;
 	ulong val;

@@ -243,7 +243,7 @@

 	pr_debug("CPM uart[-]:init portdesc\n");

-	cpm_uartnr = 0;
+	cpm_uart_nr = 0;
 #ifdef CONFIG_SERIAL_CPM_SMC1
 	cpm_uart_ports[UART_SMC1].smcp = (smc_t *) & immap->im_smc[0];
 	cpm_uart_ports[UART_SMC1].smcup =

@@ -253,7 +253,7 @@
 	cpm_uart_ports[UART_SMC1].smcp->smc_smcm |= (SMCM_RX | SMCM_TX);
 	cpm_uart_ports[UART_SMC1].smcp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
 	cpm_uart_ports[UART_SMC1].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SMC1;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SMC1;
 #endif

 #ifdef CONFIG_SERIAL_CPM_SMC2

@@ -265,7 +265,7 @@
 	cpm_uart_ports[UART_SMC2].smcp->smc_smcm |= (SMCM_RX | SMCM_TX);
 	cpm_uart_ports[UART_SMC2].smcp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
 	cpm_uart_ports[UART_SMC2].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SMC2;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SMC2;
 #endif

 #ifdef CONFIG_SERIAL_CPM_SCC1

@@ -279,7 +279,7 @@
 	cpm_uart_ports[UART_SCC1].sccp->scc_gsmrl &=
 	    ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
 	cpm_uart_ports[UART_SCC1].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SCC1;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SCC1;
 #endif

 #ifdef CONFIG_SERIAL_CPM_SCC2

@@ -293,7 +293,7 @@
 	cpm_uart_ports[UART_SCC2].sccp->scc_gsmrl &=
 	    ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
 	cpm_uart_ports[UART_SCC2].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SCC2;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SCC2;
 #endif

 #ifdef CONFIG_SERIAL_CPM_SCC3

@@ -307,7 +307,7 @@
 	cpm_uart_ports[UART_SCC3].sccp->scc_gsmrl &=
 	    ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
 	cpm_uart_ports[UART_SCC3].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SCC3;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SCC3;
 #endif

 #ifdef CONFIG_SERIAL_CPM_SCC4

@@ -321,7 +321,7 @@
 	cpm_uart_ports[UART_SCC4].sccp->scc_gsmrl &=
 	    ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
 	cpm_uart_ports[UART_SCC4].port.uartclk = (((bd_t *) __res)->bi_intfreq);
-	cpm_uartport_map[cpm_uartnr++] = UART_SCC4;
+	cpm_uart_port_map[cpm_uart_nr++] = UART_SCC4;
 #endif

 	return 0;


--

dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

David Woodhouse wrote:

[snip]

Applied

Thanks

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Thu, 2004-06-03 at 17:13 +0300, Pantelis Antoniou wrote:

Hi

The following patch updates the new CPM1/CPM2 uart driver.

It seems to lose queued characters from the kernel output when userspace
/dev/console is first opened. Should you drain the FIFO before resetting
the hardware on open? Or indeed refrain from resetting the hardware if
you're not actually changing anything?

This is with console on ttyCPM0 == SMC1. SysRq is also non-functional.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Sat, Jun 05, 2004 at 10:12:24AM +0100, David Woodhouse wrote:

On Thu, 2004-06-03 at 17:13 +0300, Pantelis Antoniou wrote:

quoted

Hi

The following patch updates the new CPM1/CPM2 uart driver.

It seems to lose queued characters from the kernel output when userspace
/dev/console is first opened. Should you drain the FIFO before resetting
the hardware on open? Or indeed refrain from resetting the hardware if
you're not actually changing anything?

I haven't seen this problem on 8xx myself.

This is with console on ttyCPM0 == SMC1. SysRq is also non-functional.

SysRq is fixed in the linuxppc-2.5 tree now.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Sat, 2004-06-05 at 12:22 -0700, Tom Rini wrote:

On Sat, Jun 05, 2004 at 10:12:24AM +0100, David Woodhouse wrote:

quoted

On Thu, 2004-06-03 at 17:13 +0300, Pantelis Antoniou wrote:

quoted

Hi

The following patch updates the new CPM1/CPM2 uart driver.

It seems to lose queued characters from the kernel output when userspace
/dev/console is first opened. Should you drain the FIFO before resetting
the hardware on open? Or indeed refrain from resetting the hardware if
you're not actually changing anything?

I haven't seen this problem on 8xx myself.

8265 here.

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k iné
sh-2.05b#

quoted

This is with console on ttyCPM0 == SMC1. SysRq is also non-functional.

SysRq is fixed in the linuxppc-2.5 tree now.

There's something weird about the console output if I hit SysRq-B. It's
as if each 32-bit word is rotated by 8 bits before being sent. The oops
I expect -- I know machine_restart() doesn't work and I'll fix if if I
have the toy in question here at home without automatic power control
for any length of time. But I do expect the oops to be readable :)

SysRq : ResettinttihMac inecchenk ir ke nelemodC.
eausyd br (fSom =RR10410 0):nTrarsfer eraor sck aignOl
:opsc maehine ch ck,:sig[ 7
 ... etc...

Also, userspace is broken without panto's _tlbia() hack in
update_mmu_cache().

Btw, someone with shell access to the linuxppc BK tree needs to manually
edit SCCS/s.ChangeSet and fix the checksum on this changeset:

ChangeSet@1.497.3879.2, 2004-04-09 10:55:30-07:00, rvinson@linuxbox.(none)
  Updating Force PCore to 2.6

This should do it:
	perl -pi -e s/K64684/K65408/ SCCS/s.ChangeSet

(for reference, if you 'bk export -tpatch' the offending cset it'll tell
you what the checksum is and what it should be.).

Then 'get ChangeSet' and it'll bitch about the checksum. Edit
SCCS/s.ChangeSet and fix the 'Hxxxxx' checksum in the very first line,
correcting it to the value it just gave you.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Sat, Jun 05, 2004 at 11:02:09PM +0100, David Woodhouse wrote:

[snip]

Btw, someone with shell access to the linuxppc BK tree needs to manually
edit SCCS/s.ChangeSet and fix the checksum on this changeset:

No-can-do.  But it's not a tree for Linus (or anyone else) to pull
directly, so that's OK.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

David Woodhouse wrote:

On Sat, 2004-06-05 at 12:22 -0700, Tom Rini wrote:

quoted

On Sat, Jun 05, 2004 at 10:12:24AM +0100, David Woodhouse wrote:

quoted

On Thu, 2004-06-03 at 17:13 +0300, Pantelis Antoniou wrote:

quoted

Hi

The following patch updates the new CPM1/CPM2 uart driver.

It seems to lose queued characters from the kernel output when userspace
/dev/console is first opened. Should you drain the FIFO before resetting
the hardware on open? Or indeed refrain from resetting the hardware if
you're not actually changing anything?

I haven't seen this problem on 8xx myself.

8265 here.

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k iné
sh-2.05b#

Hi there.

The following patch fixes the problem by properly waiting
two character times on mode change.

Regards

Pantelis

David Woodhouse wrote:

On Mon, 2004-06-07 at 11:11 +0300, Pantelis Antoniou wrote:

quoted

David Woodhouse wrote:

quoted

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k iné
sh-2.05b#

quoted

The following patch fixes the problem by properly waiting
two character times on mode change.

It had to be applied with 'patch -l' due to whitespace noise.

The patch was against my own tree, so that's explainable.
Should check better next time.

Now I get this:

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k init
                                      íbash-2.05b#

Hmm, just multiply by 3 in udelay instead of 2.

What is your baud rate? 9600?

Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 2004-06-07 at 11:11 +0300, Pantelis Antoniou wrote:

David Woodhouse wrote:

quoted

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k iné
sh-2.05b#

The following patch fixes the problem by properly waiting
two character times on mode change.

It had to be applied with 'patch -l' due to whitespace noise.

Now I get this:

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k init
                                       íbash-2.05b#


--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 2004-06-07 at 11:34 +0300, Pantelis Antoniou wrote:

Hmm, just multiply by 3 in udelay instead of 2.

What is your baud rate? 9600?

Yeah. Why must we pick numbers out of the air instead of actually
waiting for the hardware to say it's finished?

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

David Woodhouse wrote:

On Mon, 2004-06-07 at 11:34 +0300, Pantelis Antoniou wrote:

quoted

Hmm, just multiply by 3 in udelay instead of 2.

What is your baud rate? 9600?

Yeah. Why must we pick numbers out of the air instead of actually
waiting for the hardware to say it's finished?

Actually I didn't pick it out of thin air.

It is mentioned in the manual that you must wait
two character times for the HW fifo to drain.
There is no hardware event bit for FIFO empty.

It's just that the udelay call is not really exact.
So +1 and we're all OK! :)

So did it work now?

Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 2004-06-07 at 11:53 +0300, Pantelis Antoniou wrote:

It is mentioned in the manual that you must wait
two character times for the HW fifo to drain.
There is no hardware event bit for FIFO empty.

It's just that the udelay call is not really exact.
So +1 and we're all OK! :)

Ah, OK.

So did it work now?

It did; thanks.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 2004-06-07 at 11:11 +0300, Pantelis Antoniou wrote:

The following patch fixes the problem by properly waiting
two character times on mode change.

Thanks. Cleaned up and working version looks like this:

--- drivers/serial/cpm_uart/cpm_uart.h.orig	2004-06-06 16:37:05.000000000 +0100
+++ drivers/serial/cpm_uart/cpm_uart.h	2004-06-07 10:06:58.380032904 +0100

@@ -65,6 +65,8 @@
 	uint dp_addr;
 	void *mem_addr;
 	dma_addr_t dma_addr;
+	int baud;
+	int bits;
 };

 extern int cpm_uart_port_map[UART_NR];
--- drivers/serial/cpm_uart/cpm_uart_core.c.orig	2004-06-07 09:27:48.020341888 +0100
+++ drivers/serial/cpm_uart/cpm_uart_core.c	2004-06-07 10:08:41.849303184 +0100

@@ -44,6 +44,7 @@

 #include <asm/io.h>
 #include <asm/irq.h>
+#include <asm/delay.h>

 #if defined(CONFIG_SERIAL_CPM_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
 #define SUPPORT_SYSRQ

@@ -483,6 +484,10 @@
 	if ((termios->c_cflag & CREAD) == 0)
 		port->read_status_mask &= ~BD_SC_EMPTY;

+	/* if previous configuration exists wait 2 character times for tx to finish */
+	if (pinfo->baud != 0 || pinfo->bits != 0)
+		udelay((3 * 1000000 * pinfo->bits) / pinfo->baud);
+
 	spin_lock_irqsave(&port->lock, flags);

 	/* Start bit has not been added (so don't, because we would just

@@ -503,6 +508,10 @@
 	}

 	cpm_set_brg(pinfo->brg - 1, baud);
+
+	pinfo->baud = baud;
+	pinfo->bits = bits;
+
 	spin_unlock_irqrestore(&port->lock, flags);
 }


--

dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/