cpm_uart: Route SCC2 pins for the STx GP3 board

PATCH In review Matt Porter 2 participants 3 messages Jun 1, 2005 – Jun 3, 2005

lore

Share & tools

lore

Matt Porter

author

2005-06-01 17:51 UTC #0 lore raw

PATCH 1/1 cpm_uart: Route SCC2 pins for the STx GP3 board

Adds SCC2 pin routing specific to the GP3 board.

Signed-off-by Matt Porter <[email protected]>

Signed-off-by Kumar Gala <[email protected]>

drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) +9 -0

Index: drivers/serial/cpm_uart/cpm_uart_cpm2.c
===================================================================
@@ -134,12 +134,21 @@
 
 void scc2_lineif(struct uart_cpm_port *pinfo)
 {
+	/*
+	 * STx GP3 uses the SCC2 secondary option pin assignment
+	 * which this driver doesn't account for in the static
+	 * pin assignments. This kind of board specific info
+	 * really has to get out of the driver so boards can
+	 * be supported in a sane fashion.
+	 */
+#ifndef CONFIG_STX_GP3
 	volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
 	io->iop_pparb |= 0x008b0000;
 	io->iop_pdirb |= 0x00880000;
 	io->iop_psorb |= 0x00880000;
 	io->iop_pdirb &= ~0x00030000;
 	io->iop_psorb &= ~0x00030000;
+#endif
 	cpm2_immr->im_cpmux.cmx_scr &= 0xff00ffff;
 	cpm2_immr->im_cpmux.cmx_scr |= 0x00090000;
 	pinfo->brg = 2;

Andrew Morton

2005-06-02 22:34 UTC #1 lore raw

Quoted 6 lines · Matt Porter

+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644)
drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) +0 -0
@@ -134,12 +134,21 @@
 
 void scc2_lineif(struct uart_cpm_port *pinfo)
 {

drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) line 146

Quoted 10 lines

drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) +8 -0

+	/*
+	 * STx GP3 uses the SCC2 secondary option pin assignment
+	 * which this driver doesn't account for in the static
+	 * pin assignments. This kind of board specific info
+	 * really has to get out of the driver so boards can
+	 * be supported in a sane fashion.
+	 */
+#ifndef CONFIG_STX_GP3
 	volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
 	io->iop_pparb |= 0x008b0000;

Silly question: why is this driver using a volatile pointer to memory-mapped I/O rather than readl and writel?

Matt Porter

author

2005-06-03 03:29 UTC #2 lore raw

Quoted 5 lines · Andrew Morton

Quoted 4 lines · Matt Porter
+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644)
(quoted diff) +0 -0
@@ -134,12 +134,21 @@
 

Quoted 15 lines

drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) line 146
Quoted 12 lines
drivers/serial/cpm_uart/cpm_uart_cpm2.c (mode:100644) +8 -0
 void scc2_lineif(struct uart_cpm_port *pinfo)
 {
+	/*
+	 * STx GP3 uses the SCC2 secondary option pin assignment
+	 * which this driver doesn't account for in the static
+	 * pin assignments. This kind of board specific info
+	 * really has to get out of the driver so boards can
+	 * be supported in a sane fashion.
+	 */
+#ifndef CONFIG_STX_GP3
 	volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
 	io->iop_pparb |= 0x008b0000;
Silly question: why is this driver using a volatile pointer to memory-mapped I/O rather than readl and writel?

readl/writel just won't work. They are byte swapped on PPC since they are specifically for PCI access. In other "on-chip" drivers for PPC32, we typically ioremap() to a non-volatile type and then use out_be32()/in_be32() since everything except PCI on PPC is in right-endian (big endian) form. out_be*()/in_be*() contain an eieio instruction to guarantee proper ordering.

I know this driver was recently rewritten but the authors may have missed the past threads about why volatile use is discouraged. We do something similar with register overlay structures in drivers/net/ibm_emac. However, we don't use a volatile type and do use PPC32-specific (these are PPC-specific drivers anyway) out_be32()/in_be32() for correctness.

-Matt