mach/io.h cleanup and removal

cpu_relax in processor.h needs smp_mb which is defined in system.h.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/include/asm/processor.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/include/asm/processor.h +0 -0

index ce280b8..cb8d638 100644

We have compile time over-ride of ioremap, but an run-time override is needed for multi-platform builds.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/include/asm/io.h |    5 ++++-
 arch/arm/mm/ioremap.c     |    3 +++
 2 files changed, 7 insertions(+), 1 deletions(-)

arch/arm/include/asm/io.h +4 -1

index 9275828..f5c6968 100644
@@ -264,8 +264,11 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
  * Documentation/io-mapping.txt.
  *
  */
+
+extern void __iomem * (*arch_ioremap)(unsigned long, size_t, unsigned int);
+
 #ifndef __arch_ioremap
-#define __arch_ioremap			__arm_ioremap
+#define __arch_ioremap			arch_ioremap
 #define __arch_iounmap			__iounmap
 #endif
 

arch/arm/mm/ioremap.c +0 -0

index 80632e8..f551c13 100644

From: Rob Herring <[email protected]>

We have compile time over-ride of ioremap, but an run-time override is needed for multi-platform builds.

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

We have compile time over-ride of ioremap, but an run-time override is needed for multi-platform builds.

Are you sure we need this after Nicolas' updates to ioremap() ?

From: Rob Herring <[email protected]>

Convert i.MX platforms to use the common run-time ioremap hook instead of the imx specific hook.

Also, move addr_in_module out of io.h.

Signed-off-by Rob Herring <[email protected]>

From: Rob Herring <[email protected]>

Convert msm platforms to use run-time ioremap hook instead of the compile time hook.

According to David Brown, only the msm7201 needed the ioremap hook.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-msm/board-halibut.c               |    6 ++++++
 arch/arm/mach-msm/board-trout.c                 |    6 ++++++
 arch/arm/mach-msm/include/mach/io.h             |    5 -----
 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h |    6 ++++++
 arch/arm/mach-msm/io.c                          |    1 -
 5 files changed, 18 insertions(+), 6 deletions(-)

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

arch/arm/mach-at91/at91cap9.c +1 -0

index a42edc2..1fc7082 100644
@@ -21,6 +21,7 @@
 #include <mach/cpu.h>
 #include <mach/at91cap9.h>
 #include <mach/at91_pmc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91cap9_devices.c +1 -0

index d298fb7..f2edf2d 100644
@@ -27,6 +27,7 @@
 #include <mach/at91cap9.h>
 #include <mach/at91cap9_matrix.h>
 #include <mach/at91sam9_smc.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91rm9200.c +1 -0

index 99c3174..e8a4d50 100644
@@ -19,6 +19,7 @@
 #include <mach/at91_pmc.h>
 #include <mach/at91_st.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91rm9200_devices.c +1 -0

index 18bacec..1566d68 100644
@@ -21,6 +21,7 @@
 #include <mach/board.h>
 #include <mach/at91rm9200.h>
 #include <mach/at91rm9200_mc.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91rm9200_time.c +1 -0

index a028cdf..45bddca 100644
@@ -27,6 +27,7 @@
 #include <asm/mach/time.h>
 
 #include <mach/at91_st.h>
+#include <mach/at91_io.h>
 
 static unsigned long last_crtr;
 static u32 irqmask;

arch/arm/mach-at91/at91sam9260.c +1 -0

index d4036ba..5aa78fa 100644
@@ -20,6 +20,7 @@
 #include <mach/at91sam9260.h>
 #include <mach/at91_pmc.h>
 #include <mach/at91_rstc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91sam9260_devices.c +1 -0

index 642ccb6..94fdf96 100644
@@ -22,6 +22,7 @@
 #include <mach/at91sam9260.h>
 #include <mach/at91sam9260_matrix.h>
 #include <mach/at91sam9_smc.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91sam9261.c +1 -0

index 023c2ff..3b4aec7 100644
@@ -19,6 +19,7 @@
 #include <mach/at91sam9261.h>
 #include <mach/at91_pmc.h>
 #include <mach/at91_rstc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91sam9261_devices.c +1 -0

index fc59cbd..bbd04c2 100644
@@ -25,6 +25,7 @@
 #include <mach/at91sam9261.h>
 #include <mach/at91sam9261_matrix.h>
 #include <mach/at91sam9_smc.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91sam9263.c +1 -0

index 75e876c..2e1a428 100644
@@ -18,6 +18,7 @@
 #include <mach/at91sam9263.h>
 #include <mach/at91_pmc.h>
 #include <mach/at91_rstc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91sam9263_devices.c +1 -0

index 7b46b27..1e5e88d 100644
@@ -24,6 +24,7 @@
 #include <mach/at91sam9263.h>
 #include <mach/at91sam9263_matrix.h>
 #include <mach/at91sam9_smc.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91sam9g45.c +1 -0

index 1cb6a96..2f2e061 100644
@@ -19,6 +19,7 @@
 #include <mach/at91sam9g45.h>
 #include <mach/at91_pmc.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91sam9g45_devices.c +1 -0

index b7582dd..9e0de74 100644
@@ -27,6 +27,7 @@
 #include <mach/at91sam9_smc.h>
 #include <mach/at_hdmac.h>
 #include <mach/atmel-mci.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91sam9rl.c +1 -0

index d2c91a8..c284d98 100644
@@ -19,6 +19,7 @@
 #include <mach/at91sam9rl.h>
 #include <mach/at91_pmc.h>
 #include <mach/at91_rstc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

arch/arm/mach-at91/at91sam9rl_devices.c +1 -0

index 61908dc..3311106 100644
@@ -22,6 +22,7 @@
 #include <mach/at91sam9rl_matrix.h>
 #include <mach/at91sam9_smc.h>
 #include <mach/at_hdmac.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/at91x40.c +1 -0

index 56ba3bd..838103e 100644
@@ -17,6 +17,7 @@
 #include <mach/at91x40.h>
 #include <mach/at91_st.h>
 #include <mach/timex.h>
+#include <mach/at91_io.h>
 #include "generic.h"
 
 /*

arch/arm/mach-at91/at91x40_time.c +1 -0

index dfff289..152cc7a 100644
@@ -27,6 +27,7 @@
 #include <mach/hardware.h>
 #include <asm/mach/time.h>
 #include <mach/at91_tc.h>
+#include <mach/at91_io.h>
 
 /*
  *	3 counter/timer units present.

arch/arm/mach-at91/board-cap9adk.c +1 -0

index ac3de4f..b31791a 100644
@@ -44,6 +44,7 @@
 #include <mach/board.h>
 #include <mach/at91cap9_matrix.h>
 #include <mach/at91sam9_smc.h>
+#include <mach/at91_io.h>
 #include <mach/system_rev.h>
 
 #include "sam9_smc.h"

arch/arm/mach-at91/board-cpu9krea.c +1 -0

index 9ab3d1e..619d1d0 100644
@@ -43,6 +43,7 @@
 #include <mach/board.h>
 #include <mach/at91sam9_smc.h>
 #include <mach/at91sam9260_matrix.h>
+#include <mach/at91_io.h>
 
 #include "sam9_smc.h"
 #include "generic.h"

arch/arm/mach-at91/board-eco920.c +1 -0

index 07ef35b..f56bf24 100644
@@ -27,6 +27,7 @@
 #include <mach/board.h>
 #include <mach/at91rm9200_mc.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/board-yl-9200.c +1 -0

index bbd553e..bf889e5 100644
@@ -46,6 +46,7 @@
 #include <mach/board.h>
 #include <mach/at91rm9200_mc.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 

arch/arm/mach-at91/clock.c +1 -0

index 61873f3..0e8b318 100644
@@ -27,6 +27,7 @@
 #include <mach/hardware.h>
 #include <mach/at91_pmc.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "clock.h"
 #include "generic.h"

arch/arm/mach-at91/include/mach/at91_io.h new file +0 -0

new file mode 100644
index 0000000..82e66de

arch/arm/mach-at91/include/mach/at91_io.h new file +10 -0

+ *
+ *  Copyright (C) 2003 SAN People
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of

arch/arm/mach-at91/include/mach/at91_io.h new file +22 -0

+
+#include <mach/hardware.h>
+
+#ifndef __ASSEMBLY__
+
+static inline unsigned int at91_sys_read(unsigned int reg_offset)
+{
+	void __iomem *addr = (void __iomem *)AT91_VA_BASE_SYS;
+
+	return __raw_readl(addr + reg_offset);
+}
+
+static inline void at91_sys_write(unsigned int reg_offset, unsigned long value)
+{
+	void __iomem *addr = (void __iomem *)AT91_VA_BASE_SYS;
+
+	__raw_writel(value, addr + reg_offset);
+}
+
+#endif
+
+#endif

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +0 -0

index e2f8da8..0427212 100644

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

+
 #define AT91_DDRSDRC_MR		0x00	/* Mode Register */
 #define		AT91_DDRSDRC_MODE	(0x7 << 0)		/* Command Mode */
 #define			AT91_DDRSDRC_MODE_NORMAL	0

arch/arm/mach-at91/include/mach/at91sam9_sdramc.h +2 -0

index 100f5a5..4a3b2ec 100644
@@ -16,6 +16,8 @@
 #ifndef AT91SAM9_SDRAMC_H
 #define AT91SAM9_SDRAMC_H
 
+#include <mach/at91_io.h>
+
 /* SDRAM Controller (SDRAMC) registers */
 #define AT91_SDRAMC_MR		0x00	/* SDRAM Controller Mode Register */
 #define		AT91_SDRAMC_MODE	(0xf << 0)		/* Command Mode */

arch/arm/mach-at91/include/mach/uncompress.h +1 -0

index 0234fd9..96dd8e1 100644
@@ -23,6 +23,7 @@
 
 #include <linux/io.h>
 #include <linux/atmel_serial.h>
+#include <mach/at91_io.h>
 
 #if defined(CONFIG_AT91_EARLY_DBGU0)
 #define UART_OFFSET AT91_BASE_DBGU0

arch/arm/mach-at91/pm.c +1 -0

index 1606379..f099c3e 100644
@@ -27,6 +27,7 @@
 
 #include <mach/at91_pmc.h>
 #include <mach/cpu.h>
+#include <mach/at91_io.h>
 
 #include "generic.h"
 #include "pm.h"

arch/arm/mach-at91/pm.h +2 -0

index 7eb40d2..ac12592 100644
@@ -1,3 +1,5 @@
+#include <mach/at91_io.h>
+
 #ifdef CONFIG_ARCH_AT91RM9200
 #include <mach/at91rm9200_mc.h>
 

arch/arm/mach-at91/setup.c +1 -0

index 69d3fc4..cee8156 100644
@@ -17,6 +17,7 @@
 #include <mach/at91_dbgu.h>
 #include <mach/at91_pmc.h>
 #include <mach/at91_shdwc.h>
+#include <mach/at91_io.h>
 
 #include "soc.h"
 #include "generic.h"

drivers/pcmcia/at91_cf.c +1 -0

index 4902206..3edf52b 100644
@@ -26,6 +26,7 @@
 
 #include <mach/board.h>
 #include <mach/at91rm9200_mc.h>
+#include <mach/at91_io.h>
 
 
 /*

drivers/rtc/rtc-at91sam9.c +1 -1

index a3ad957..d044f55 100644
@@ -23,7 +23,7 @@
 #include <mach/board.h>
 #include <mach/at91_rtt.h>
 #include <mach/cpu.h>
-
+#include <mach/at91_io.h>
 
 /*
  * This driver uses two configurable hardware resources that live in the

drivers/usb/gadget/at91_udc.c +1 -0

index 143a725..e9da936 100644
@@ -41,6 +41,7 @@
 #include <mach/board.h>
 #include <mach/cpu.h>
 #include <mach/at91sam9261_matrix.h>
+#include <mach/at91_io.h>
 
 #include "at91_udc.h"
 

drivers/watchdog/at91rm9200_wdt.c +1 -0

index b3046dc..4073312 100644
@@ -22,6 +22,7 @@
 #include <linux/types.h>
 #include <linux/watchdog.h>
 #include <linux/uaccess.h>
+#include <mach/at91_io.h>
 #include <mach/at91_st.h>
 
 #define WDT_DEFAULT_TIME	5	/* seconds */

drivers/watchdog/at91sam9_wdt.c +1 -0

index 0056256..d4c0576 100644
@@ -31,6 +31,7 @@
 #include <linux/bitops.h>
 #include <linux/uaccess.h>
 
+#include <mach/at91_io.h>
 #include "at91sam9_wdt.h"
 
 #define DRV_NAME "AT91SAM9 Watchdog"

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 9 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 
+#include <mach/at91_io.h>

Do we need this include in header files?

Quoted 5 lines · Nicolas Ferre

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 8 lines

Quoted 8 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +0 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 

Quoted 3 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 1 line

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

+#include <mach/at91_io.h>

Do we need this include in header files?

Yes, for at91_sys_write/read used at the bottom.

Quoted 64 lines · Rob Herring

Quoted 5 lines · Nicolas Ferre

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 8 lines

Quoted 8 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +0 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 

Quoted 5 lines

Quoted 3 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 1 line

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

+#include <mach/at91_io.h>

Do we need this include in header files?

Yes, for at91_sys_write/read used at the bottom.

no need I droped the at91_sys_read/write for 3.4

Quoted 69 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 68 lines · Rob Herring

Quoted 5 lines · Nicolas Ferre

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 11 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 9 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 
+#include <mach/at91_io.h>

Do we need this include in header files?

Quoted 3 lines

Quoted 1 line

Yes, for at91_sys_write/read used at the bottom.

no need I droped the at91_sys_read/write for 3.4

Everywhere or just this header? Is this in a stable branch somewhere?

Quoted 70 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 69 lines · Rob Herring

Quoted 68 lines · Nicolas Ferre

Quoted 5 lines

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 11 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 9 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 
+#include <mach/at91_io.h>

Do we need this include in header files?

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Yes, for at91_sys_write/read used at the bottom.

no need I droped the at91_sys_read/write for 3.4

Everywhere or just this header? Is this in a stable branch somewhere?

everywhere

I'm preparing it

On 02/16/2012 03:23 PM, Jean-Christophe PLAGNIOL-VILLARD :

Quoted 71 lines · Rob Herring

Quoted 70 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 69 lines · Rob Herring

Quoted 68 lines · Nicolas Ferre

Quoted 5 lines

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 11 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 9 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 
+#include <mach/at91_io.h>

Do we need this include in header files?

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Yes, for at91_sys_write/read used at the bottom.

no need I droped the at91_sys_read/write for 3.4

Everywhere or just this header? Is this in a stable branch somewhere?

everywhere

I'm preparing it

Jean and I have worked on this for the last two weeks... and I think that we have something you can take as an example:
git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

I will not qualify this branch as "stable" as it is not yet included in arm-soc git tree (pull request sent at the very moment). But I think that you will be able to rely on it once it will be included in arm-soc. On the other hand, if it sound too late for you, we can adapt your work on top of that new branch of ours.

Quoted 85 lines · Nicolas Ferre

On 02/16/2012 03:23 PM, Jean-Christophe PLAGNIOL-VILLARD :

Quoted 71 lines · Rob Herring

Quoted 70 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 69 lines · Rob Herring

Quoted 68 lines · Nicolas Ferre

Quoted 5 lines

On 02/13/2012 10:43 PM, Rob Herring :

Quoted 4 lines

From: Rob Herring <[email protected]>

Move most of io.h into at91_io.h and update includes.

Quoted 8 lines

Quoted 4 lines

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-at91/at91cap9.c                     |    1 +
 arch/arm/mach-at91/at91cap9_devices.c             |    1 +

Please do not touch the "*cap9*" files anymore: They are scheduled for removal for 3.4 kernel:
Documentation/feature-removal-schedule.txt

Okay.

Quoted 36 lines

Quoted 36 lines

 arch/arm/mach-at91/at91rm9200.c                   |    1 +
 arch/arm/mach-at91/at91rm9200_devices.c           |    1 +
 arch/arm/mach-at91/at91rm9200_time.c              |    1 +
 arch/arm/mach-at91/at91sam9260.c                  |    1 +
 arch/arm/mach-at91/at91sam9260_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9261.c                  |    1 +
 arch/arm/mach-at91/at91sam9261_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9263.c                  |    1 +
 arch/arm/mach-at91/at91sam9263_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9g45.c                  |    1 +
 arch/arm/mach-at91/at91sam9g45_devices.c          |    1 +
 arch/arm/mach-at91/at91sam9rl.c                   |    1 +
 arch/arm/mach-at91/at91sam9rl_devices.c           |    1 +
 arch/arm/mach-at91/at91x40.c                      |    1 +
 arch/arm/mach-at91/at91x40_time.c                 |    1 +
 arch/arm/mach-at91/board-cap9adk.c                |    1 +
 arch/arm/mach-at91/board-cpu9krea.c               |    1 +
 arch/arm/mach-at91/board-eco920.c                 |    1 +
 arch/arm/mach-at91/board-yl-9200.c                |    1 +
 arch/arm/mach-at91/clock.c                        |    1 +
 arch/arm/mach-at91/include/mach/at91_io.h         |   44 +++++++++++++++++++++
 arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h |    2 +
 arch/arm/mach-at91/include/mach/at91sam9_sdramc.h |    2 +
 arch/arm/mach-at91/include/mach/uncompress.h      |    1 +
 arch/arm/mach-at91/pm.c                           |    1 +
 arch/arm/mach-at91/pm.h                           |    2 +
 arch/arm/mach-at91/setup.c                        |    1 +
 drivers/pcmcia/at91_cf.c                          |    1 +
 drivers/rtc/rtc-at91sam9.c                        |    2 +-
 drivers/usb/gadget/at91_udc.c                     |    1 +
 drivers/watchdog/at91rm9200_wdt.c                 |    1 +
 drivers/watchdog/at91sam9_wdt.c                   |    1 +
 34 files changed, 80 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/at91_io.h

snip

Quoted 11 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h line 15

Quoted 9 lines

arch/arm/mach-at91/include/mach/at91sam9_ddrsdr.h +1 -0

index e2f8da8..0427212 100644
@@ -12,6 +12,8 @@
 #ifndef AT91SAM9_DDRSDR_H
 #define AT91SAM9_DDRSDR_H
 
+#include <mach/at91_io.h>

Do we need this include in header files?

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Yes, for at91_sys_write/read used at the bottom.

no need I droped the at91_sys_read/write for 3.4

Everywhere or just this header? Is this in a stable branch somewhere?

everywhere

I'm preparing it

Jean and I have worked on this for the last two weeks... and I think that we have something you can take as an example:
git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

Quoted 5 lines

I will not qualify this branch as "stable" as it is not yet included in arm-soc git tree (pull request sent at the very moment). But I think that you will be able to rely on it once it will be included in arm-soc. On the other hand, if it sound too late for you, we can adapt your work on top of that new branch of ours.

With this branch and io.h removed, I just get 1 error with uncompress.h needing an explicit include:

In file included from /home/rob/proj/git/linux-2.6/arch/arm/boot/compressed/misc.c:28:0:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:
In function ?putc?:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:55:39:
error: ?AT91_BASE_DBGU0? undeclared (first use in this function) /home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:55:39:
note: each undeclared identifier is reported only once for each function it appears in /home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:
In function ?flush?:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:66:39:
error: ?AT91_BASE_DBGU0? undeclared (first use in this function) make[3]: *** [arch/arm/boot/compressed/misc.o] Error 1
CC arch/arm/boot/compressed/decompress.o
In file included from /home/rob/proj/git/linux-2.6/arch/arm/boot/compressed/misc.c:28:0:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:
In function ?putc?:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:55:39:

error: ?AT91_BASE_DBGU0? undeclared (first use in this function) /home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:55:39:
note: each undeclared identifier is reported only once for each function it appears in /home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:
In function ?flush?:
/home/rob/proj/git/linux-2.6/arch/arm/mach-at91/include/mach/uncompress.h:66:39:
error: ?AT91_BASE_DBGU0? undeclared (first use in this function)

From: Rob Herring <[email protected]>

Move ep93xx specifics in mach/io.h to ep93xx-regs.h.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h +0 -0

index c4a7b84..8933c62 100644

Quoted 17 lines · Rob Herring

From: Rob Herring <[email protected]>

Move ep93xx specifics in mach/io.h to ep93xx-regs.h.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h +0 -0

index c4a7b84..8933c62 100644
@@ -25,6 +25,12 @@
  *	http://www.cirrus.com/en/pubs/appNote/AN273REV4.pdf
  */
 

arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h line 33

Quoted 6 lines

arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h +6 -0

+#ifdef __ASSEMBLER__
+#define IOMEM(p)                p
+#else
+#define IOMEM(p)                ((void __iomem __force *)(p))
+#endif
+

I think you will get multiple definition warnings with this patch applied, but not the later patches (think git bisect, etc). For example, arch/arm/mach-ep93xx/clock.c includes both linux/io.h (includes mach/io.h) and mach/hardware.h (includes mach/ep93xx-regs.h) so you will get warnings about IOMEM being redefined.

Move ep93xx specifics in mach/io.h to ep93xx-regs.h.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h +0 -0

index c4a7b84..8933c62 100644
@@ -25,6 +25,12 @@
  *	http://www.cirrus.com/en/pubs/appNote/AN273REV4.pdf
  */

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does. Most PCI platforms need mach/io.h for now, but ks8695 doesn't which means it's broken? omap has a lot of other stuff in its io.h, so it also needs io.h until it is cleaned up.

Signed-off-by Rob Herring <[email protected]>

---
 arch/arm/Kconfig          |   21 +++++++++++++++++++++
 arch/arm/include/asm/io.h |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

Quoted 6 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

In other words, if you have PCI or ISA and your __io() macro is a 1:1 translation, you _need_ an io.h to define a proper offset for this.

So, I think this patch series moves things in the wrong direction.

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Quoted 2 lines

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

So, I think this patch series moves things in the wrong direction.

Quoted 5 lines · Russell King - ARM Linux

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Quoted 8 lines

Quoted 2 lines

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

Right. I still think it should be conditional on PCI || ISA || PCMCIA, not introducing a new kconfig symbol, and the next step should be to unify the __io() implementations for the platforms that need them.

Quoted 1 line

So, I think this patch series moves things in the wrong direction.

I would very much like to see a lot of the series get merged as it brings us closer to the single zimage, but I agree we have to be careful not to add extra complexity (or bugs, for that matter).

Arnd,

Quoted 15 lines · Arnd Bergmann

Quoted 5 lines · Russell King - ARM Linux

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Quoted 8 lines

Quoted 2 lines

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

Quoted 3 lines

Right. I still think it should be conditional on PCI || ISA || PCMCIA, not introducing a new kconfig symbol, and the next step should be to unify the __io() implementations for the platforms that need them.

As we discussed at Connect, that was my original intent. However, there are a couple of issues as NEED_MACH_IO_H is not exactly equivalent to PCI || ISA || PCMCIA.

There are a few platforms which still need io.h for custom accessor
functions: rpc, ixp4xx, s3c2410, and ebsa110.

Also, a few platforms that
only select ISA don't do any translation in __io(). These are sa1100, clps711x, and pxa. My understanding is that is wrong.

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

Quoted 22 lines · Rob Herring

Arnd,

Quoted 15 lines · Arnd Bergmann

Quoted 5 lines · Russell King - ARM Linux

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Quoted 8 lines

Quoted 2 lines

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

Quoted 3 lines

Right. I still think it should be conditional on PCI || ISA || PCMCIA, not introducing a new kconfig symbol, and the next step should be to unify the __io() implementations for the platforms that need them.

Quoted 6 lines

As we discussed at Connect, that was my original intent. However, there are a couple of issues as NEED_MACH_IO_H is not exactly equivalent to PCI || ISA || PCMCIA.

There are a few platforms which still need io.h for custom accessor
functions: rpc, ixp4xx, s3c2410, and ebsa110.

I've tried to interpret what is there, please correct me if this is wrong:

RPC and ebsa110 have ISA, or some twisted version of that. I believe RPC doesn't select CONFIG_ISA because it has no actual ISA slots but it still uses legacy ISA I/O and we might just select it anyway.

s3c24xx seems to have ISA in a similar way on the "bast" machine, while the setup code for that got copied into some platforms that don't really require it.

ixp4xx has PCI, but does not always use direct MMIO to access the memory or I/O spaces.

I guess the only way we can ever make these ones use a common header file (in case we care) by letting them go through an indirect struct io_ops { u8 (*inb)(int); void (*outb)(u8, int); ... };, but we might not care enough.

Quoted 3 lines

Also, a few platforms that
only select ISA don't do any translation in __io(). These are sa1100, clps711x, and pxa. My understanding is that is wrong.

sa1100 has pcmcia slots that use their own method (setting io_offset) of redirecting the i/o space into the right location. As Russell mentioned, this is broken if you load an ISA device driver that uses hardcoded port numbers, or as I might add when you use /dev/port.

pxa seems to do the same as sa1100 for PCMCIA and PCI, but I can't figure out what they do for ISA. I suspect they only enable that in order to get ISA device drivers for PCMCIA based add-on cards.

clps711x for all I can tell is broken as you say.

I think omap1 and at91 fit into the same category as sa1100 and pxa regarding pcmcia. All four can in theory be converted to use a common virtual mapping as we want to have for PCI.

Quoted 4 lines

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);

}
#else
static inline void __iomem *__io(unsigned long addr)

{
        return NULL;
}

#endif
#define __io(a) __io(a)

Out of the platforms supporting PCI right now, we currently have these three classes:

1. portable, but using different virtual addresses:
arch/arm/mach-integrator/include/mach/io.h:#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a)))
arch/arm/mach-ixp23xx/include/mach/io.h:#define __io(p) ((void __iomem*)((p) + IXP23XX_PCI_IO_VIRT))
arch/arm/mach-ixp2000/include/mach/io.h:#define __io(p) ((void __iomem *)((p)+IXP2000_PCI_IO_VIRT_BASE))
arch/arm/mach-shark/include/mach/io.h:#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
arch/arm/mach-footbridge/include/mach/io.h:#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
arch/arm/mach-tegra/include/mach/io.h:static inline void __iomem *__io(unsigned long addr) arch/arm/mach-kirkwood/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)
arch/arm/mach-dove/include/mach/io.h:#define __io(a) ((void __iomem *)(((a) - DOVE_PCIE0_IO_BUS_BASE) + \

2. Does not map the I/O space, or does not use it -- I cannot see how any of these use PIO based PCI devices at all, probably broken already:
arch/arm/mach-cns3xxx/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-ixp4xx/include/mach/io.h:#define __io(v) __typesafe_io(v)
arch/arm/mach-ks8695/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-orion5x/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-sa1100/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-pxa/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-versatile/include/mach/io.h:#define __io(a) __typesafe_io(a)

3. scary multi-way translation, needs someone to really understand (Nico?, Lennert?)
arch/arm/mach-iop32x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop33x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop13xx/include/mach/io.h:#define __io(a) __iop13xx_io(a) arch/arm/mach-mv78xx0/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)

I think if we can figure out the third category, this should all become fairly easy for PCI based platforms.

Arnd

Quoted 18 lines · Arnd Bergmann

Quoted 4 lines · Rob Herring

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

Quoted 3 lines

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);

But don't we want a constant pci_io_base? This would certainly be a quicker conversion, but I don't think we want to do it twice.

Quoted 37 lines

}
#else
static inline void __iomem *__io(unsigned long addr)

{
        return NULL;
}

#endif
#define __io(a) __io(a)

Out of the platforms supporting PCI right now, we currently have these three classes:

1. portable, but using different virtual addresses:
arch/arm/mach-integrator/include/mach/io.h:#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a)))
arch/arm/mach-ixp23xx/include/mach/io.h:#define __io(p) ((void __iomem*)((p) + IXP23XX_PCI_IO_VIRT))
arch/arm/mach-ixp2000/include/mach/io.h:#define __io(p) ((void __iomem *)((p)+IXP2000_PCI_IO_VIRT_BASE))
arch/arm/mach-shark/include/mach/io.h:#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
arch/arm/mach-footbridge/include/mach/io.h:#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
arch/arm/mach-tegra/include/mach/io.h:static inline void __iomem *__io(unsigned long addr) arch/arm/mach-kirkwood/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)
arch/arm/mach-dove/include/mach/io.h:#define __io(a) ((void __iomem *)(((a) - DOVE_PCIE0_IO_BUS_BASE) + \

2. Does not map the I/O space, or does not use it -- I cannot see how any of these use PIO based PCI devices at all, probably broken already:
arch/arm/mach-cns3xxx/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-ixp4xx/include/mach/io.h:#define __io(v) __typesafe_io(v)
arch/arm/mach-ks8695/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-orion5x/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-sa1100/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-pxa/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-versatile/include/mach/io.h:#define __io(a) __typesafe_io(a)

3. scary multi-way translation, needs someone to really understand (Nico?, Lennert?)
arch/arm/mach-iop32x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop33x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop13xx/include/mach/io.h:#define __io(a) __iop13xx_io(a) arch/arm/mach-mv78xx0/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)

Quoted 3 lines

I think if we can figure out the third category, this should all become fairly easy for PCI based platforms.

This looks correct AFAICT.

We could just call the 3rd category legacy and move on.

Quoted 23 lines · Rob Herring

Quoted 21 lines · Arnd Bergmann

Quoted 4 lines · Rob Herring

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);

Quoted 2 lines

But don't we want a constant pci_io_base? This would certainly be a quicker conversion, but I don't think we want to do it twice.

Yes, at least in the long run. Note that this should make no difference at all from a performance point of view, but it does impact code size a bit.

Quoted 2 lines

Yes, at least in the long run. Note that this should make no difference at all from a performance point of view, but it does impact code size a bit.

That depends whether the additional reloads of pci_io_base can be properly scheduled by the compiler, and experience shows that you tend to end up with the load delay slot not being filled on older processors.

Not only that, but the compiler will evaluate the entire:

pci_io_base + (addr & IO_SPACE_LIMIT)

thing every time. With a 64K mask, that will include reloading the mask every single access.

So, we'll probably end up with about three additional loads per IO operation, none of which would be scheduled particularly well.

"Yuck" and "not in my kernel" comes to mind.

Quoted 24 lines · Arnd Bergmann

Quoted 23 lines · Rob Herring

Quoted 21 lines · Arnd Bergmann

Quoted 4 lines · Rob Herring

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);

Quoted 5 lines

Quoted 2 lines

But don't we want a constant pci_io_base? This would certainly be a quicker conversion, but I don't think we want to do it twice.

Yes, at least in the long run. Note that this should make no difference at all from a performance point of view, but it does impact code size a bit.

That depends whether the additional reloads of pci_io_base can be properly scheduled by the compiler, and experience shows that you tend to end up with the load delay slot _not_ being filled on older processors.

Not only that, but the compiler _will_ evaluate the entire:

pci_io_base + (addr & IO_SPACE_LIMIT)

thing every time. With a 64K mask, that will include _reloading_ the mask every single access.

So, we'll probably end up with about three additional loads per IO operation, none of which would be scheduled particularly well.

"Yuck" and "not in my kernel" comes to mind.

What about something like this:

io.h:
#define PCI_IO_VIRT_BASE 0xfef00000

arch/arm/common/pci.c (new file):

static struct map_desc pci_io_desc[] __initdata = {
	{
		.virtual	= PCI_IO_VIRT_BASE,
		.pfn		= 0,
		.length		= SZ_1M,
		.type		= MT_DEVICE,
	},
};

void __init pci_map_io(unsigned long paddr)

{
	pci_io_desc[0].pfn = __phys_to_pfn(paddr);
	iotable_init(pci_io_desc, ARRAY_SIZE(pci_io_desc));
}

This is using the last 1MB of vmalloc region. This may require some adjustment of platform's static memory, but most PCI platforms I've checked don't use this address, so it shouldn't be too painful.

orion5x maps 2 1MB regions for PCI and PCIE. How would you support 2 io ranges?

BTW, I noticed some static mappings at 0xffxxxxxx. Are those even a valid address?

Quoted 2 lines · Rob Herring

BTW, I noticed some static mappings at 0xffxxxxxx. Are those even a valid address?

Nothing invalid about them as such, but I have tried to discourage their use in case we decide that we want to go for a default 14MB DMA region.

Quoted 6 lines · Russell King - ARM Linux

Quoted 2 lines · Rob Herring

BTW, I noticed some static mappings at 0xffxxxxxx. Are those even a valid address?

Nothing invalid about them as such, but I have tried to discourage their use in case we decide that we want to go for a default 14MB DMA region.

They should be invalid, and would be flagged by this code in create_mapping():

        if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
            md->virtual >= PAGE_OFFSET &&
            (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) 
        {
                printk(KERN_WARNING "BUG: mapping for 0x%08llx"
                       " at 0x%08lx out of vmalloc space\n",
                       (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
        }

given that VMALLOC_END is now defined as 0xff000000.

What are those static mappings at 0xffxxxxxx? I was looking for them while reworking this code but I might have missed some.

Quoted 2 lines

orion5x maps 2 1MB regions for PCI and PCIE. How would you support 2 io ranges?

That's not the only platform which effectively has two IO ranges. The PCMCIA sockets on SA11x0 and probably PXA both have their own separate IO region. Arnd's idea for this was to map 32k from one and 32k from the other into a single 64k space, and adapt soc_common to cope.

Quoted 2 lines

BTW, I noticed some static mappings at 0xffxxxxxx. Are those even a valid address?

Nothing invalid about them as such, but I have tried to discourage their use in case we decide that we want to go for a default 14MB DMA region.

Quoted 19 lines · Rob Herring

Quoted 18 lines · Arnd Bergmann

Quoted 4 lines · Rob Herring

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

Quoted 6 lines

Quoted 3 lines

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);

But don't we want a constant pci_io_base? This would certainly be a quicker conversion, but I don't think we want to do it twice.

Yes, at least in the long run. Note that this should make no difference at all from a performance point of view, but it does impact code size a bit.

Quoted 43 lines

Quoted 31 lines

}
#else
static inline void __iomem *__io(unsigned long addr)

{
        return NULL;
}

#endif
#define __io(a) __io(a)

Out of the platforms supporting PCI right now, we currently have these three classes:

1. portable, but using different virtual addresses:
arch/arm/mach-integrator/include/mach/io.h:#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a)))
arch/arm/mach-ixp23xx/include/mach/io.h:#define __io(p) ((void __iomem*)((p) + IXP23XX_PCI_IO_VIRT))
arch/arm/mach-ixp2000/include/mach/io.h:#define __io(p) ((void __iomem *)((p)+IXP2000_PCI_IO_VIRT_BASE))
arch/arm/mach-shark/include/mach/io.h:#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
arch/arm/mach-footbridge/include/mach/io.h:#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
arch/arm/mach-tegra/include/mach/io.h:static inline void __iomem *__io(unsigned long addr) arch/arm/mach-kirkwood/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)
arch/arm/mach-dove/include/mach/io.h:#define __io(a) ((void __iomem *)(((a) - DOVE_PCIE0_IO_BUS_BASE) + \

2. Does not map the I/O space, or does not use it -- I cannot see how any of these use PIO based PCI devices at all, probably broken already:
arch/arm/mach-cns3xxx/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-ixp4xx/include/mach/io.h:#define __io(v) __typesafe_io(v)
arch/arm/mach-ks8695/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-orion5x/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-sa1100/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-pxa/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-versatile/include/mach/io.h:#define __io(a) __typesafe_io(a)

Quoted 9 lines

3. scary multi-way translation, needs someone to really understand (Nico?, Lennert?)
arch/arm/mach-iop32x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop33x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop13xx/include/mach/io.h:#define __io(a) __iop13xx_io(a) arch/arm/mach-mv78xx0/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)

I think if we can figure out the third category, this should all become fairly easy for PCI based platforms.

This looks correct AFAICT.

Quoted 1 line

We could just call the 3rd category legacy and move on.

I'm not ready to give up that fast. The platforms seem to be implemented reasonably well compared to category 2, but they can't be converted in a completely mechanical way. The patch below should put iop13xx it into category 1, but it really needs testing and review by a person who understands that platform. I can also take a look at the others if we agree that this is the right approach.

When we have all platforms done in that way, we can move the virtual mapping base to a fixed location.

8<--------------
[PATCH] iop13xx: use more regular PCI I/O space handling

iop13xx confuses I/O port numbers with physical addresses, which breaks legacy ISA I/O access behind PCI bridges and makes it unnecessarily hard to unify the inb/outb accessors with other platforms. This removes the special-casing and just puts all I/O ports into a single 128KB virtually mapped I/O port range starting at port zero.

Signed-off-by Arnd Bergmann <[email protected]>

---
 arch/arm/mach-iop13xx/include/mach/io.h      |    6 +++-
 arch/arm/mach-iop13xx/include/mach/iop13xx.h |   12 ++--------
 arch/arm/mach-iop13xx/io.c                   |   27 --------------------------
 arch/arm/mach-iop13xx/pci.c                  |   12 +++++-----
 4 files changed, 13 insertions(+), 44 deletions(-)

arch/arm/mach-iop13xx/include/mach/io.h +4 -2

index dffb234..90bb7df 100644
@@ -19,9 +19,11 @@
 #ifndef __ASM_ARM_ARCH_IO_H
 #define __ASM_ARM_ARCH_IO_H
 
-#define IO_SPACE_LIMIT 0xffffffff
+#include <mach/iop13xx.h>
 
-#define __io(a) __iop13xx_io(a)
+#define IO_SPACE_LIMIT (IOP13XX_PCIE_IO_WINDOW_SIZE + IOP13XX_PCIX_IO_WINDOW_SIZE - 1)
+
+#define __io(a) (IOP13XX_PCIX_LOWER_IO_VA + ((a) & IO_SPACE_LIMIT))
 #define __mem_pci(a) (a)
 #define __mem_isa(a) (a)
 

arch/arm/mach-iop13xx/include/mach/iop13xx.h +3 -9

index 07e9ff7..ee1dfd2 100644
@@ -68,17 +68,15 @@ extern unsigned long get_iop_tick_rate(void);
  * 0x8000.0000 + 928M	0x2.8000.0000   (ioremap)	PCIE outbound memory window
  *
  * IO MAP
- * 0x1000 + 64K	0x0.fffb.1000	0xfec6.1000	PCIX outbound i/o window
+ * 0x1000 + 64K	0x0.fffb.1000	0xfed6.1000	PCIX outbound i/o window
  * 0x1000 + 64K	0x0.fffd.1000	0xfed7.1000	PCIE outbound i/o window
  */
 #define IOP13XX_PCIX_IO_WINDOW_SIZE   0x10000UL
 #define IOP13XX_PCIX_LOWER_IO_PA      0xfffb0000UL
-#define IOP13XX_PCIX_LOWER_IO_VA      0xfec60000UL
+#define IOP13XX_PCIX_LOWER_IO_VA      0xfed60000UL
 #define IOP13XX_PCIX_LOWER_IO_BA      0x0UL /* OIOTVR */
 #define IOP13XX_PCIX_IO_BUS_OFFSET    0x1000UL
-#define IOP13XX_PCIX_UPPER_IO_PA      (IOP13XX_PCIX_LOWER_IO_PA +\
-				       IOP13XX_PCIX_IO_WINDOW_SIZE - 1)
-#define IOP13XX_PCIX_UPPER_IO_VA      (IOP13XX_PCIX_LOWER_IO_VA +\
+#define IOP13XX_PCIX_UPPER_IO_BA      (IOP13XX_PCIX_LOWER_IO_BA +\
 				       IOP13XX_PCIX_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIX_IO_PHYS_TO_VIRT(addr) (u32) ((u32) addr -\
 					   (IOP13XX_PCIX_LOWER_IO_PA\

@@ -107,10 +105,6 @@ extern unsigned long get_iop_tick_rate(void);
 #define IOP13XX_PCIE_LOWER_IO_VA      	 0xfed70000UL
 #define IOP13XX_PCIE_LOWER_IO_BA      	 0x0UL  /* OIOTVR */
 #define IOP13XX_PCIE_IO_BUS_OFFSET	 0x1000UL
-#define IOP13XX_PCIE_UPPER_IO_PA      	 (IOP13XX_PCIE_LOWER_IO_PA +\
-					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
-#define IOP13XX_PCIE_UPPER_IO_VA      	 (IOP13XX_PCIE_LOWER_IO_VA +\
-					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIE_UPPER_IO_BA      	 (IOP13XX_PCIE_LOWER_IO_BA +\
 					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIE_IO_PHYS_TO_VIRT(addr) (u32) ((u32) addr -\

arch/arm/mach-iop13xx/io.c +0 -27

index 48642e6..7a1ab4d 100644
@@ -21,25 +21,6 @@
 #include <linux/io.h>
 #include <mach/hardware.h>
 
-void * __iomem __iop13xx_io(unsigned long io_addr)
-{
-	void __iomem * io_virt;
-
-	switch (io_addr) {
-	case IOP13XX_PCIE_LOWER_IO_PA ... IOP13XX_PCIE_UPPER_IO_PA:
-		io_virt = (void *) IOP13XX_PCIE_IO_PHYS_TO_VIRT(io_addr);
-		break;
-	case IOP13XX_PCIX_LOWER_IO_PA ... IOP13XX_PCIX_UPPER_IO_PA:
-		io_virt = (void *) IOP13XX_PCIX_IO_PHYS_TO_VIRT(io_addr);
-		break;
-	default:
-		BUG();
-	}
-
-	return io_virt;
-}
-EXPORT_SYMBOL(__iop13xx_io);
-
 void * __iomem __iop13xx_ioremap(unsigned long cookie, size_t size,
 	unsigned int mtype)
 {

@@ -65,12 +46,6 @@ void * __iomem __iop13xx_ioremap(unsigned long cookie, size_t size,
 				       (cookie - IOP13XX_PBI_LOWER_MEM_RA),
 				       size, mtype, __builtin_return_address(0));
 		break;
-	case IOP13XX_PCIE_LOWER_IO_PA ... IOP13XX_PCIE_UPPER_IO_PA:
-		retval = (void *) IOP13XX_PCIE_IO_PHYS_TO_VIRT(cookie);
-		break;
-	case IOP13XX_PCIX_LOWER_IO_PA ... IOP13XX_PCIX_UPPER_IO_PA:
-		retval = (void *) IOP13XX_PCIX_IO_PHYS_TO_VIRT(cookie);
-		break;
 	case IOP13XX_PMMR_PHYS_MEM_BASE ... IOP13XX_PMMR_UPPER_MEM_PA:
 		retval = (void *) IOP13XX_PMMR_PHYS_TO_VIRT(cookie);
 		break;

@@ -100,8 +75,6 @@ void __iop13xx_iounmap(void __iomem *addr)
 		    goto skip;
 
 	switch ((u32) addr) {
-	case IOP13XX_PCIE_LOWER_IO_VA ... IOP13XX_PCIE_UPPER_IO_VA:
-	case IOP13XX_PCIX_LOWER_IO_VA ... IOP13XX_PCIX_UPPER_IO_VA:
 	case IOP13XX_PMMR_VIRT_MEM_BASE ... IOP13XX_PMMR_UPPER_MEM_VA:
 		goto skip;
 	}

arch/arm/mach-iop13xx/pci.c +6 -6

index b8f5a87..d72eddf 100644
@@ -1042,8 +1042,8 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 				  << IOP13XX_ATUX_PCIXSR_FUNC_NUM;
 		__raw_writel(pcixsr, IOP13XX_ATUX_PCIXSR);
 
-		res[0].start = IOP13XX_PCIX_LOWER_IO_PA + IOP13XX_PCIX_IO_BUS_OFFSET;
-		res[0].end   = IOP13XX_PCIX_UPPER_IO_PA;
+		res[0].start = IOP13XX_PCIX_LOWER_IO_BA + IOP13XX_PCIX_IO_BUS_OFFSET;
+		res[0].end   = IOP13XX_PCIX_UPPER_IO_BA;
 		res[0].name  = "IQ81340 ATUX PCI I/O Space";
 		res[0].flags = IORESOURCE_IO;
 

@@ -1052,7 +1052,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 		res[1].name  = "IQ81340 ATUX PCI Memory Space";
 		res[1].flags = IORESOURCE_MEM;
 		sys->mem_offset = IOP13XX_PCIX_MEM_OFFSET;
-		sys->io_offset = IOP13XX_PCIX_LOWER_IO_PA;
+		sys->io_offset = IOP13XX_PCIX_LOWER_IO_BA;
 		break;
 	case IOP13XX_INIT_ATU_ATUE:
 		/* Note: the function number field in the PCSR is ro */

@@ -1063,8 +1063,8 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 
 		__raw_writel(pcsr, IOP13XX_ATUE_PCSR);
 
-		res[0].start = IOP13XX_PCIE_LOWER_IO_PA + IOP13XX_PCIE_IO_BUS_OFFSET;
-		res[0].end   = IOP13XX_PCIE_UPPER_IO_PA;
+		res[0].start = IOP13XX_PCIE_LOWER_IO_BA + IOP13XX_PCIE_IO_BUS_OFFSET;
+		res[0].end   = IOP13XX_PCIE_UPPER_IO_BA;
 		res[0].name  = "IQ81340 ATUE PCI I/O Space";
 		res[0].flags = IORESOURCE_IO;
 

@@ -1073,7 +1073,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 		res[1].name  = "IQ81340 ATUE PCI Memory Space";
 		res[1].flags = IORESOURCE_MEM;
 		sys->mem_offset = IOP13XX_PCIE_MEM_OFFSET;
-		sys->io_offset = IOP13XX_PCIE_LOWER_IO_PA;
+		sys->io_offset = IOP13XX_PCIE_LOWER_IO_BA;
 		sys->map_irq = iop13xx_pcie_map_irq;
 		break;
 	default:

Quoted 12 lines

Quoted 4 lines

This looks correct AFAICT.

We could just call the 3rd category legacy and move on.

I'm not ready to give up that fast. The platforms seem to be implemented reasonably well compared to category 2, but they can't be converted in a completely mechanical way. The patch below should put iop13xx it into category 1, but it really needs testing and review by a person who understands that platform. I can also take a look at the others if we agree that this is the right approach.

It looks fine to me and I'm happy to pull it in, but who can test? There's almost no commits specific to iop13xx going back to 2009. The PCI related code goes back to 2007. I've added a couple of Intel folks that did the original support.

Quoted 22 lines · Rob Herring

Arnd,

Quoted 15 lines · Arnd Bergmann

Quoted 5 lines · Russell King - ARM Linux

Quoted 4 lines · Rob Herring

From: Rob Herring <[email protected]>

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Quoted 8 lines

Quoted 2 lines

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does.

This is architecturally wrong. If you have ISA, and your __io() macro is essentially a 1:1 translation, you're asking for ISA drivers to scribble on whatever is at virtual address 0-64K. Too bad if that happens to be where your CPU vectors are stored, you'll lose control of the CPU in that case.

Quoted 3 lines

Right. I still think it should be conditional on PCI || ISA || PCMCIA, not introducing a new kconfig symbol, and the next step should be to unify the __io() implementations for the platforms that need them.

Quoted 6 lines

As we discussed at Connect, that was my original intent. However, there are a couple of issues as NEED_MACH_IO_H is not exactly equivalent to PCI || ISA || PCMCIA.

There are a few platforms which still need io.h for custom accessor
functions: rpc, ixp4xx, s3c2410, and ebsa110.

I've tried to interpret what is there, please correct me if this is wrong:

RPC and ebsa110 have ISA, or some twisted version of that. I believe RPC doesn't select CONFIG_ISA because it has no actual ISA slots but it still uses legacy ISA I/O and we might just select it anyway.

s3c24xx seems to have ISA in a similar way on the "bast" machine, while the setup code for that got copied into some platforms that don't really require it.

ixp4xx has PCI, but does not always use direct MMIO to access the memory or I/O spaces.

I guess the only way we can ever make these ones use a common header file (in case we care) by letting them go through an indirect struct io_ops { u8 (*inb)(int); void (*outb)(u8, int); ... };, but we might not care enough.

Quoted 3 lines

Also, a few platforms that
only select ISA don't do any translation in __io(). These are sa1100, clps711x, and pxa. My understanding is that is wrong.

sa1100 has pcmcia slots that use their own method (setting io_offset) of redirecting the i/o space into the right location. As Russell mentioned, this is broken if you load an ISA device driver that uses hardcoded port numbers, or as I might add when you use /dev/port.

pxa seems to do the same as sa1100 for PCMCIA and PCI, but I can't figure out what they do for ISA. I suspect they only enable that in order to get ISA device drivers for PCMCIA based add-on cards.

clps711x for all I can tell is broken as you say.

I think omap1 and at91 fit into the same category as sa1100 and pxa regarding pcmcia. All four can in theory be converted to use a common virtual mapping as we want to have for PCI.

Quoted 4 lines

If we use CONFIG_PCI, then we have to move over all PCI enabled platforms at once. With a separate kconfig option, then we can move platforms one by one. Some are legacy and we may not want to move. This also helped with omap, but Tony has now fixed it.

We could also generalize the implementation from tegra, which seems reasonable as a start:

#define IO_SPACE_LIMIT 0xffff

#if defined(CONFIG_ISA) || defined(CONFIG_PCCARD)
#include <mach/io.h>
#elif defined(CONFIG_PCI)
extern void __iomem *pci_io_base;

static inline void __iomem *__io(unsigned long addr)

{
        return pci_io_base + (addr & IO_SPACE_LIMIT);
}
#else
static inline void __iomem *__io(unsigned long addr)
{
        return NULL;
}

#endif
#define __io(a) __io(a)

Out of the platforms supporting PCI right now, we currently have these three classes:

1. portable, but using different virtual addresses:
arch/arm/mach-integrator/include/mach/io.h:#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a)))
arch/arm/mach-ixp23xx/include/mach/io.h:#define __io(p) ((void __iomem*)((p) + IXP23XX_PCI_IO_VIRT))
arch/arm/mach-ixp2000/include/mach/io.h:#define __io(p) ((void __iomem *)((p)+IXP2000_PCI_IO_VIRT_BASE))
arch/arm/mach-shark/include/mach/io.h:#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
arch/arm/mach-footbridge/include/mach/io.h:#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
arch/arm/mach-tegra/include/mach/io.h:static inline void __iomem *__io(unsigned long addr) arch/arm/mach-kirkwood/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)
arch/arm/mach-dove/include/mach/io.h:#define __io(a) ((void __iomem *)(((a) - DOVE_PCIE0_IO_BUS_BASE) + \

2. Does not map the I/O space, or does not use it -- I cannot see how any of these use PIO based PCI devices at all, probably broken already:
arch/arm/mach-cns3xxx/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-ixp4xx/include/mach/io.h:#define __io(v) __typesafe_io(v)
arch/arm/mach-ks8695/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-orion5x/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-sa1100/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-pxa/include/mach/io.h:#define __io(a) __typesafe_io(a)
arch/arm/mach-versatile/include/mach/io.h:#define __io(a) __typesafe_io(a)

3. scary multi-way translation, needs someone to really understand (Nico?, Lennert?)
arch/arm/mach-iop32x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop33x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop13xx/include/mach/io.h:#define __io(a) __iop13xx_io(a) arch/arm/mach-mv78xx0/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)

Quoted 5 lines

3. scary multi-way translation, needs someone to really understand (Nico?, Lennert?)
arch/arm/mach-iop32x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop33x/include/mach/io.h:#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))
arch/arm/mach-iop13xx/include/mach/io.h:#define __io(a) __iop13xx_io(a) arch/arm/mach-mv78xx0/include/mach/io.h:static inline void __iomem *__io(unsigned long addr)

It seems iop3xx and mv78xx0 are just setting the PCI bus address to the local bus address. The OIOWTVR register controls local bus to PCI address translation. It is set to 0x90000000 which is effectively no translation.

But don't we really want 0x9000xxxx local bus translated to 0x0000xxxx PCI bus? Then the io resource region is setup for 0x9000xxxx as well. If both the PCI bus address and i/o resources are moved to 0x0 that should make these category 1.

Also, you've left off ixp4xx from this list. It has PCI and needs io.h, so fixing all the PCI platforms above will not make using CONFIG_PCI, ISA or PCMCIA to include mach/io.h or not work. However, if indirect io is all that io.h is needed for then perhaps a config option called NEEDS_INDIRECT_IO would be a better name.

Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h.

Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does. Most PCI platforms need mach/io.h for now, but ks8695 doesn't which means it's broken? omap has a lot of other stuff in its io.h, so it also needs io.h until it is cleaned up.

Signed-off-by Rob Herring <[email protected]>

arch/arm/include/asm/io.h static inline void __iomem *__typesafe_io(unsigned long addr) · line 117

Quoted 6 lines

arch/arm/include/asm/io.h +5 -0

+#ifdef CONFIG_NEED_MACH_IO_H
 #include <mach/io.h>
+#else
+#define __io(a)              ({ (void)(a); __typesafe_io(0); })
+#define __mem_pci(a) (a)
+#endif

Rob,

I compile and boot tested these patches on EP93xxbut did not check them with sparse.

Most of the mach/io.h headers you remove in Patch 14/15 have the __io macro defined like:

#define __io(a) __typesafe_io(a)

Does your change above still keep the __io macro typesafe?

They don't appear equivalent to me...

Quoted 12 lines · H Hartley Sweeten

arch/arm/include/asm/io.h static inline void __iomem *__typesafe_io(unsigned long addr) · line 117

Quoted 6 lines

arch/arm/include/asm/io.h +5 -0

+#ifdef CONFIG_NEED_MACH_IO_H
 #include <mach/io.h>
+#else
+#define __io(a)              ({ (void)(a); __typesafe_io(0); })
+#define __mem_pci(a) (a)
+#endif

Rob,

I compile and boot tested these patches on EP93xxbut did not check them with sparse.

Quoted 8 lines

Most of the mach/io.h headers you remove in Patch 14/15 have the __io macro defined like:

#define __io(a) __typesafe_io(a)

Does your change above still keep the __io macro typesafe?

They don't appear equivalent to me...

It's not equivalent, but the new version is more correct for most platforms because it turns a random pointer dereference into a NULL pointer dereference.

If you have none of PCI/ISA/PCMCIA, then inb/outb should never be used. Ideally we would undefine __io in that case, which results in the inb/outb stuff also not getting defined, but some drivers like 8250 serial then fail to build even for systems that only use the readl/writel path.

outb(v,p)

{
        __iowmb();
        __raw_writeb(v, /* not sure what happens to the (void)p */ (void __iomem *)0);
}

To me the original one looks more correct. With Rob's change it looks to me like all the in/out macros end up reading/writing to address 0.

I don't get what's happening in Rob's change. Could you enlighten me?