io.h clean-up for PCI

GIT PULL Rob Herring 5 participants 21 messages Jul 16, 2012 – Aug 28, 2012

Subsystems (2)

Arm (32-bit) Arm sub-architectures

lore

Share & tools

lore

Rob Herring

author

2012-07-16 22:15 UTC #0 lore raw

Arnd,

Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.

BTW, I'll have sporadic email access over the next 2 weeks.

Rob

The following changes since commit bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a:

Linux 3.5-rc6 (2012-07-07 17:23:56 -0700)

are available in the git repository at:

git://sources.calxeda.com/kernel/linux.git io-cleanup-pci

for you to fetch changes up to 52f1412fb6415b7608745972bbcba56739d0d11e:

ARM: iop3xx: use fixed PCI i/o mapping (2012-07-16 16:56:41 -0500)

----------------------------------------------------------------
Arnd Bergmann (1):
iop13xx: use more regular PCI I/O space handling

Rob Herring (16):
i2c: iop3xx: clean-up trailing whitespace
i2c: iop3xx: use standard gpiolib functions
ARM: Add fixed PCI i/o mapping
ARM: move PCI i/o resource setup into common code
ARM: versatile: use fixed PCI i/o mapping
ARM: tegra: use fixed PCI i/o mapping
ARM: integrator: use fixed PCI i/o mapping
ARM: integrator: remove trailing whitespace on pci_v3.c
ARM: shark: use fixed PCI i/o mapping
ARM: footbridge: use fixed PCI i/o mapping
ARM: dove: use fixed PCI i/o mapping
ARM: kirkwood: use fixed PCI i/o mapping
ARM: orion5x: use fixed PCI i/o mapping
ARM: iop13xx: use fixed PCI i/o mapping
ARM: mv78xx0: use fixed pci i/o mapping
ARM: iop3xx: use fixed PCI i/o mapping

 Documentation/arm/memory.txt                       |    3 +
 arch/arm/Kconfig                                   |   13 +--
 arch/arm/include/asm/hardware/iop3xx.h             |   12 +-
 arch/arm/include/asm/io.h                          |    8 ++
 arch/arm/include/asm/mach/map.h                    |    8 ++
 arch/arm/include/asm/mach/pci.h                    |   18 +++
 arch/arm/kernel/bios32.c                           |   42 ++++++-
 arch/arm/mach-dove/common.c                        |   10 --
 arch/arm/mach-dove/include/mach/dove.h             |    8 +-
 arch/arm/mach-dove/include/mach/io.h               |   19 ---
 arch/arm/mach-dove/pcie.c                          |   43 +++----
 arch/arm/mach-footbridge/common.c                  |    8 +-
 arch/arm/mach-footbridge/dc21285.c                 |   16 +--
 .../arm/mach-footbridge/include/mach/debug-macro.S |    3 +-
 arch/arm/mach-footbridge/include/mach/io.h         |   12 +-
 arch/arm/mach-integrator/include/mach/io.h         |   33 ------
 arch/arm/mach-integrator/include/mach/platform.h   |    4 +
 arch/arm/mach-integrator/integrator_ap.c           |    7 +-
 arch/arm/mach-integrator/pci_v3.c                  |   50 ++++----
 arch/arm/mach-iop13xx/include/mach/io.h            |   28 -----
 arch/arm/mach-iop13xx/include/mach/iop13xx.h       |   27 +----
 arch/arm/mach-iop13xx/io.c                         |   27 -----
 arch/arm/mach-iop13xx/pci.c                        |   37 +++---
 arch/arm/mach-iop13xx/setup.c                      |   10 --
 arch/arm/mach-iop32x/include/mach/io.h             |   19 ---
 arch/arm/mach-iop33x/include/mach/io.h             |   19 ---
 arch/arm/mach-kirkwood/common.c                    |   10 --
 arch/arm/mach-kirkwood/include/mach/io.h           |   24 ----
 arch/arm/mach-kirkwood/include/mach/kirkwood.h     |    8 +-
 arch/arm/mach-kirkwood/pcie.c                      |   44 +++----
 arch/arm/mach-mv78xx0/addr-map.c                   |    3 +-
 arch/arm/mach-mv78xx0/common.c                     |    5 -
 arch/arm/mach-mv78xx0/include/mach/io.h            |   24 ----
 arch/arm/mach-mv78xx0/include/mach/mv78xx0.h       |   21 ++--
 arch/arm/mach-mv78xx0/pcie.c                       |  110
++++++------------
 arch/arm/mach-orion5x/common.c                     |   10 --
 arch/arm/mach-orion5x/include/mach/io.h            |   22 ----
 arch/arm/mach-orion5x/include/mach/orion5x.h       |   20 ++--
 arch/arm/mach-orion5x/pci.c                        |   56 +++------
 arch/arm/mach-shark/core.c                         |   18 ---
 arch/arm/mach-shark/include/mach/debug-macro.S     |    7 +-
 arch/arm/mach-shark/include/mach/entry-macro.S     |    3 +-
 arch/arm/mach-shark/include/mach/io.h              |   18 ---
 arch/arm/mach-shark/pci.c                          |    5 +
 arch/arm/mach-tegra/include/mach/io.h              |   46 --------
 arch/arm/mach-tegra/include/mach/iomap.h           |    3 +
 arch/arm/mach-tegra/pcie.c                         |   95 ++++-----------
 arch/arm/mach-versatile/core.c                     |    5 -
 arch/arm/mach-versatile/include/mach/hardware.h    |    1 -
 arch/arm/mach-versatile/include/mach/io.h          |   27 -----
 arch/arm/mach-versatile/pci.c                      |   22 +---
 arch/arm/mm/ioremap.c                              |   14 +++
 arch/arm/mm/mmu.c                                  |   26 +++--
 arch/arm/plat-iop/pci.c                            |   25 ++--
 arch/arm/plat-iop/setup.c                          |    5 -
 drivers/i2c/busses/i2c-iop3xx.c                    |  121
++++++++++----------
 56 files changed, 377 insertions(+), 905 deletions(-)
 delete mode 100644 arch/arm/mach-dove/include/mach/io.h
 delete mode 100644 arch/arm/mach-integrator/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop32x/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop33x/include/mach/io.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/io.h
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/io.h
 delete mode 100644 arch/arm/mach-orion5x/include/mach/io.h
 delete mode 100644 arch/arm/mach-shark/include/mach/io.h
 delete mode 100644 arch/arm/mach-tegra/include/mach/io.h
 delete mode 100644 arch/arm/mach-versatile/include/mach/io.h

Arnd Bergmann

2012-07-17 20:53 UTC #1 lore raw

Quoted 6 lines · Rob Herring

Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.

Pulled into staging/io-cleanup-pci, and I added the introductory text from your patch series as a merge changeset comment.

Thanks for this great series, I hope we can make it for this merge window.

Arnd

Arnd Bergmann

2012-07-19 14:12 UTC #2 lore raw

In reply to Rob Herring

Quoted 6 lines · Rob Herring

Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.

I think we need this one:

iop13xx ended up with two conflicting definitions for IOP13XX_PCIE_LOWER_IO_BA, where one of them is used to set up the hardware window and should be zero, while the other one is used to set the location of the second mapping into the virtual address space.

This kills the second definition and hardcodes the 64KB offset that is already hardcoded in the bios32.c file now.

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

index 9278b8c..cc9e058 100644

arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1

@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA      	 0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA      	 0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA      	 0x10000UL
 
 #define IOP13XX_PCIE_MEM_PHYS_OFFSET  	 0x200000000ULL
 #define IOP13XX_PCIE_MEM_WINDOW_SIZE  	 0x3a000000UL

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

index 56a4b41..9cad41b 100644
@@ -1058,7 +1058,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 
 		__raw_writel(pcsr, IOP13XX_ATUE_PCSR);
 
-		pci_ioremap_io(IOP13XX_PCIE_LOWER_IO_BA, IOP13XX_PCIE_LOWER_IO_PA);
+		pci_ioremap_io(SZ_64K, IOP13XX_PCIE_LOWER_IO_PA);
 
 		res->start = IOP13XX_PCIE_LOWER_MEM_RA;
 		res->end   = IOP13XX_PCIE_UPPER_MEM_RA;

Rob Herring

author

2012-07-24 12:33 UTC #3 lore raw

Quoted 25 lines · Arnd Bergmann

Quoted 6 lines · Rob Herring
Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.
I think we need this one:
iop13xx ended up with two conflicting definitions for IOP13XX_PCIE_LOWER_IO_BA, where one of them is used to set up the hardware window and should be zero, while the other one is used to set the location of the second mapping into the virtual address space.
This kills the second definition and hardcodes the 64KB offset that is already hardcoded in the bios32.c file now.
Signed-off-by Arnd Bergmann <[email protected]>
index 9278b8c..cc9e058 100644

arch/arm/mach-iop13xx/include/mach/iop13xx.h extern unsigned long get_iop_tick_rate(void); · line 98

Quoted 4 lines

arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1

@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA      	 0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA      	 0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA      	 0x10000UL

This means we have PCIE and PCIX buses both using i/o bus addresses starting at 0x0. We can't have that, right?

The requested resource won't match either as the resource start address is bus_nr * 64K.

Rob

Quoted 18 lines

arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -0

 #define IOP13XX_PCIE_MEM_PHYS_OFFSET  	 0x200000000ULL
 #define IOP13XX_PCIE_MEM_WINDOW_SIZE  	 0x3a000000UL

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

index 56a4b41..9cad41b 100644
@@ -1058,7 +1058,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 
 		__raw_writel(pcsr, IOP13XX_ATUE_PCSR);
 
-		pci_ioremap_io(IOP13XX_PCIE_LOWER_IO_BA, IOP13XX_PCIE_LOWER_IO_PA);
+		pci_ioremap_io(SZ_64K, IOP13XX_PCIE_LOWER_IO_PA);
 
 		res->start = IOP13XX_PCIE_LOWER_MEM_RA;
 		res->end   = IOP13XX_PCIE_UPPER_MEM_RA;

Arnd Bergmann

2012-07-24 12:43 UTC #4 lore raw

Quoted 11 lines · Rob Herring

arch/arm/mach-iop13xx/include/mach/iop13xx.h extern unsigned long get_iop_tick_rate(void); · line 98
Quoted 7 lines
arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1
@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA              0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA              0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA              0x10000UL
This means we have PCIE and PCIX buses both using i/o bus addresses starting at 0x0. We can't have that, right?

Quoted 2 lines

The requested resource won't match either as the resource start address is bus_nr * 64K.

Well, this is the number that gets written into the outbound translation window register, which has to be zero AFAICT.

The PCI device you plug into the bus will always see its io ports as being between zero and 65536 -- the part that stays at 0x10000UL is the offset address that we use in Linux to give it a unique address in the virtual address space window we use to cover all the io port ranges.

The io_offset still gets set to 0x10000, so this number always gets added and subtracted when converting between Linux port numbers and bus-specific port numbers.

Arnd

Rob Herring

author

2012-07-24 13:25 UTC #5 lore raw

Quoted 24 lines · Arnd Bergmann

Quoted 11 lines · Rob Herring
arch/arm/mach-iop13xx/include/mach/iop13xx.h extern unsigned long get_iop_tick_rate(void); · line 98
Quoted 7 lines
arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1
@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA              0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA              0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA              0x10000UL
This means we have PCIE and PCIX buses both using i/o bus addresses starting at 0x0. We can't have that, right?
Quoted 2 lines
The requested resource won't match either as the resource start address is bus_nr * 64K.
Well, this is the number that gets written into the outbound translation window register, which has to be zero AFAICT.
The PCI device you plug into the bus will always see its io ports as being between zero and 65536 -- the part that stays at 0x10000UL is the offset address that we use in Linux to give it a unique address in the virtual address space window we use to cover all the io port ranges.

Quoted 3 lines

The io_offset still gets set to 0x10000, so this number always gets added and subtracted when converting between Linux port numbers and bus-specific port numbers.

Okay, then this is probably something I need to fix.

How is mem_offset supposed to be set? Generally memory is setup as cpu base paddr = pci mem addr, so mem_offset should be 0? But integrator is set to the cpu paddr, and it works.

Rob

Quoted 3 lines

Arnd

Arnd Bergmann

2012-07-24 14:18 UTC #6 lore raw

Quoted 3 lines · Rob Herring

How is mem_offset supposed to be set? Generally memory is setup as cpu base paddr = pci mem addr, so mem_offset should be 0? But integrator is set to the cpu paddr, and it works.

I don't really know. I would assume that setting mem_offset to something other than 0 means your bus address space is not the same as the cpu address space. The window that is usable by PCI should be specified in the memory resource, not using the mem_offset, but I could be interpreting that incorrectly.

Arnd

Rob Herring

author

2012-07-25 14:41 UTC #7 lore raw

In reply to Arnd Bergmann

Quoted 24 lines · Arnd Bergmann

Quoted 11 lines · Rob Herring
arch/arm/mach-iop13xx/include/mach/iop13xx.h extern unsigned long get_iop_tick_rate(void); · line 98
Quoted 7 lines
arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1
@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA              0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA              0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA              0x10000UL
This means we have PCIE and PCIX buses both using i/o bus addresses starting at 0x0. We can't have that, right?
Quoted 2 lines
The requested resource won't match either as the resource start address is bus_nr * 64K.
Well, this is the number that gets written into the outbound translation window register, which has to be zero AFAICT.
The PCI device you plug into the bus will always see its io ports as being between zero and 65536 -- the part that stays at 0x10000UL is the offset address that we use in Linux to give it a unique address in the virtual address space window we use to cover all the io port ranges.

Quoted 3 lines

The io_offset still gets set to 0x10000, so this number always gets added and subtracted when converting between Linux port numbers and bus-specific port numbers.

I don't think this is going to work right with the orion family. They set the 2nd+ buses to some non-zero bus value.

{ 0, KIRKWOOD_PCIE_IO_PHYS_BASE, KIRKWOOD_PCIE_IO_SIZE,
TARGET_PCIE, ATTR_PCIE_IO, KIRKWOOD_PCIE_IO_BUS_BASE

This is 0.

},
{ 1, KIRKWOOD_PCIE_MEM_PHYS_BASE, KIRKWOOD_PCIE_MEM_SIZE,
TARGET_PCIE, ATTR_PCIE_MEM, KIRKWOOD_PCIE_MEM_BUS_BASE
},
{ 2, KIRKWOOD_PCIE1_IO_PHYS_BASE, KIRKWOOD_PCIE1_IO_SIZE,
TARGET_PCIE, ATTR_PCIE1_IO, KIRKWOOD_PCIE1_IO_BUS_BASE

This was 0x100000 and is now 0x10000.

	},
	{ 3, KIRKWOOD_PCIE1_MEM_PHYS_BASE, KIRKWOOD_PCIE1_MEM_SIZE,
	  TARGET_PCIE, ATTR_PCIE1_MEM, KIRKWOOD_PCIE1_MEM_BUS_BASE
	},

If we change all these to 0, then I need to go back thru all the platforms.

Rob

Arnd Bergmann

2012-07-25 15:52 UTC #8 lore raw

Quoted 44 lines · Rob Herring

Quoted 24 lines · Arnd Bergmann
Quoted 11 lines · Rob Herring
arch/arm/mach-iop13xx/include/mach/iop13xx.h extern unsigned long get_iop_tick_rate(void); · line 98
Quoted 7 lines
arch/arm/mach-iop13xx/include/mach/iop13xx.h +0 -1
@@ -95,7 +95,6 @@ extern unsigned long get_iop_tick_rate(void);
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA              0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_BA              0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA              0x10000UL
This means we have PCIE and PCIX buses both using i/o bus addresses starting at 0x0. We can't have that, right?
Quoted 2 lines
The requested resource won't match either as the resource start address is bus_nr * 64K.
Well, this is the number that gets written into the outbound translation window register, which has to be zero AFAICT.
The PCI device you plug into the bus will always see its io ports as being between zero and 65536 -- the part that stays at 0x10000UL is the offset address that we use in Linux to give it a unique address in the virtual address space window we use to cover all the io port ranges.
Quoted 3 lines
The io_offset still gets set to 0x10000, so this number always gets added and subtracted when converting between Linux port numbers and bus-specific port numbers.
I don't think this is going to work right with the orion family. They set the 2nd+ buses to some non-zero bus value.
{ 0, KIRKWOOD_PCIE_IO_PHYS_BASE, KIRKWOOD_PCIE_IO_SIZE,
TARGET_PCIE, ATTR_PCIE_IO, KIRKWOOD_PCIE_IO_BUS_BASE
This is 0.
},
{ 1, KIRKWOOD_PCIE_MEM_PHYS_BASE, KIRKWOOD_PCIE_MEM_SIZE,
TARGET_PCIE, ATTR_PCIE_MEM, KIRKWOOD_PCIE_MEM_BUS_BASE
},
{ 2, KIRKWOOD_PCIE1_IO_PHYS_BASE, KIRKWOOD_PCIE1_IO_SIZE,
TARGET_PCIE, ATTR_PCIE1_IO, KIRKWOOD_PCIE1_IO_BUS_BASE

Quoted 8 lines

This was 0x100000 and is now 0x10000.
},
{ 3, KIRKWOOD_PCIE1_MEM_PHYS_BASE, KIRKWOOD_PCIE1_MEM_SIZE,
TARGET_PCIE, ATTR_PCIE1_MEM, KIRKWOOD_PCIE1_MEM_BUS_BASE
},
If we change all these to 0, then I need to go back thru all the platforms.

You are right, this is different from what I thought. Do you think this is for a similar setup register to the one used on IOP13xx?

For all I know, the code in iop13xx has always used a zero here, while kirkwood/dove/mv78xx0/orion did not. I believe it can work either way, as long as that register matches what we set up in the sys->io_offset variable.

With my patch for iop13xx, it does not, since set both the sys->io_offset variable and the OIOTVR register to zero, but let the resource start at 64K. I'm pretty sure now that my patch was broken because of this. If so, I would prefer to leave io_offset at zero and change the register again.

How is this for a change?

Arnd

8<----

Quoted 1 line

From 2012ce83ebbfdee38d2cfc42ab7a8352fe1b95f6 Mon Sep 17 00:00:00 2001

From: Arnd Bergmann <[email protected]>
Date: Thu, 19 Jul 2012 14:12:00 +0000
Subject: [PATCH] ARM: iop13xx: remove duplicate IOP13XX_PCIE_LOWER_IO_BA

iop13xx ended up with two conflicting definitions for IOP13XX_PCIE_LOWER_IO_BA, where one of them is used to set up the hardware window and was traditionally zero, while the other one is used to set the location of the second mapping into the virtual address space.

This kills the extraneous definition and uses the 64KB offset that is already hardcoded in the bios32.c file now for storing in the register as well.

Let's hope this works. If it does not, the alternative would be to revert the value we write into OIOTVR to zero and set sys->io_offset to 64K.

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

arch/arm/mach-iop13xx/include/mach/iop13xx.h +1 -2

index 9278b8c..e10e101 100644
@@ -94,8 +94,7 @@ extern unsigned long get_iop_tick_rate(void);
 
 /* PCI-E ranges */
 #define IOP13XX_PCIE_LOWER_IO_PA      	 0xfffd0000UL
-#define IOP13XX_PCIE_LOWER_IO_BA      	 0x0UL  /* OIOTVR */
-#define IOP13XX_PCIE_LOWER_IO_BA      	 0x10000UL
+#define IOP13XX_PCIE_LOWER_IO_BA	 0x10000UL  /* OIOTVR */
 
 #define IOP13XX_PCIE_MEM_PHYS_OFFSET  	 0x200000000ULL
 #define IOP13XX_PCIE_MEM_WINDOW_SIZE  	 0x3a000000UL

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

index f3826bb..91f731a 100644
@@ -1058,7 +1058,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)
 
 		__raw_writel(pcsr, IOP13XX_ATUE_PCSR);
 
-		pci_ioremap_io(IOP13XX_PCIE_LOWER_IO_BA, IOP13XX_PCIE_LOWER_IO_PA);
+		pci_ioremap_io(SZ_64K, IOP13XX_PCIE_LOWER_IO_PA);
 
 		res->start = IOP13XX_PCIE_LOWER_MEM_RA;
 		res->end   = IOP13XX_PCIE_UPPER_MEM_RA;

Arnd Bergmann

2012-07-19 14:16 UTC #9 lore raw

In reply to Rob Herring

Quoted 6 lines · Rob Herring

Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.

I've alrady applied this patch on top, which was rather obvious.

Arnd

commit 960760557356fba9e86698605d1e1c68783d72e3

Author: Arnd Bergmann <[email protected]>
Date:   Thu Jul 19 16:13:41 2012 +0200

ARM: pci: mark pci_reserve_io as __init

pci_reserve_io calls the vm_reserve_area_early function that is marked __init, so it needs to be __init itself to avoid this warning:

WARNING: arch/arm/mm/built-in.o(.text+0x22dc): Section mismatch in reference from the function pci_reserve_io() to the function .init.text:vm_reserve_area_early()

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

arch/arm/include/asm/mach/pci.h +1 -1

index 6345a5f..188fd58 100644
@@ -64,7 +64,7 @@ void pci_common_init(struct hw_pci *);
  */
 #if defined(CONFIG_PCI) && !defined(CONFIG_NEED_MACH_IO_H)
 /* Called from devicemaps_init before .map_io */
-static inline void pci_reserve_io(void)
+static inline void __init pci_reserve_io(void)
 {
 	vm_reserve_area_early(PCI_IO_VIRT_BASE, SZ_2M, pci_reserve_io);
 }

Rob Herring

author

2012-07-23 00:35 UTC #10 lore raw

In reply to Rob Herring

Quoted 7 lines · Rob Herring

Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.

I found a collision with EDAC enum mem_type and ARM struct mem_type definitions. It's caused from pulling in asm/mach/map.h into asm/mach/pci.h. I've reworked things which avoids the to avoid that. You want a rebased branch with the fix and other issues you found or just the following patch?

arch/arm/include/asm/mach/pci.h +3 -1

index 188fd58..78d10a8 100644
@@ -12,7 +12,6 @@
 #define __ASM_MACH_PCI_H
 
 #include <linux/ioport.h>
-#include <asm/mach/map.h>
 
 struct pci_sys_data;
 struct pci_ops;

@@ -63,6 +62,9 @@ void pci_common_init(struct hw_pci *);
  * Setup fixed I/O mapping.
  */
 #if defined(CONFIG_PCI) && !defined(CONFIG_NEED_MACH_IO_H)
+extern void vm_reserve_area_early(unsigned long addr, unsigned long size,
+				  void *caller);
+
 /* Called from devicemaps_init before .map_io */
 static inline void __init pci_reserve_io(void)
 {

Rob Herring

author

2012-07-27 21:59 UTC #11 lore raw

In reply to Rob Herring

Quoted 9 lines · Rob Herring

Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.
Rob

Arnd,

Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:

- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
- Avoid including map.h in asm/mach/pci.h which collided with EDAC.

Rob

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:

Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

are available in the git repository at:

git://sources.calxeda.com/kernel/linux.git io-cleanup-pci-v2

for you to fetch changes up to dd9bf78040fa0da4cecc228e1682b9682b8cb180:

ARM: iop3xx: use fixed PCI i/o mapping (2012-07-26 09:10:04 -0500)

----------------------------------------------------------------
Arnd Bergmann (1):
iop13xx: use more regular PCI I/O space handling

 Documentation/arm/memory.txt                       |    3 +
 arch/arm/Kconfig                                   |   13 +--
 arch/arm/include/asm/hardware/iop3xx.h             |   12 +-
 arch/arm/include/asm/io.h                          |    8 ++
 arch/arm/include/asm/mach/map.h                    |    8 ++
 arch/arm/include/asm/mach/pci.h                    |   13 +++
 arch/arm/kernel/bios32.c                           |   54 ++++++++-
 arch/arm/mach-dove/common.c                        |   10 --
 arch/arm/mach-dove/include/mach/dove.h             |    8 +-
 arch/arm/mach-dove/include/mach/io.h               |   19 ---
 arch/arm/mach-dove/pcie.c                          |   43 +++----
 arch/arm/mach-footbridge/common.c                  |   12 +-
 arch/arm/mach-footbridge/dc21285.c                 |   16 +--
 .../arm/mach-footbridge/include/mach/debug-macro.S |    3 +-
 arch/arm/mach-footbridge/include/mach/io.h         |   12 +-
 arch/arm/mach-integrator/include/mach/io.h         |   33 ------
 arch/arm/mach-integrator/include/mach/platform.h   |    4 +
 arch/arm/mach-integrator/integrator_ap.c           |    9 +-
 arch/arm/mach-integrator/pci_v3.c                  |   50 ++++----
 arch/arm/mach-iop13xx/include/mach/io.h            |   28 -----
 arch/arm/mach-iop13xx/include/mach/iop13xx.h       |   28 +----
 arch/arm/mach-iop13xx/io.c                         |   27 -----
 arch/arm/mach-iop13xx/pci.c                        |   37 +++---
 arch/arm/mach-iop13xx/setup.c                      |   10 --
 arch/arm/mach-iop32x/include/mach/io.h             |   19 ---
 arch/arm/mach-iop33x/include/mach/io.h             |   19 ---
 arch/arm/mach-kirkwood/common.c                    |   10 --
 arch/arm/mach-kirkwood/include/mach/io.h           |   24 ----
 arch/arm/mach-kirkwood/include/mach/kirkwood.h     |    8 +-
 arch/arm/mach-kirkwood/pcie.c                      |   44 +++----
 arch/arm/mach-mv78xx0/addr-map.c                   |    3 +-
 arch/arm/mach-mv78xx0/common.c                     |    5 -
 arch/arm/mach-mv78xx0/include/mach/io.h            |   24 ----
 arch/arm/mach-mv78xx0/include/mach/mv78xx0.h       |   21 ++--
 arch/arm/mach-mv78xx0/pcie.c                       |  110
++++++------------
 arch/arm/mach-orion5x/common.c                     |   10 --
 arch/arm/mach-orion5x/include/mach/io.h            |   22 ----
 arch/arm/mach-orion5x/include/mach/orion5x.h       |   20 ++--
 arch/arm/mach-orion5x/pci.c                        |   56 +++------
 arch/arm/mach-shark/core.c                         |   18 ---
 arch/arm/mach-shark/include/mach/debug-macro.S     |    7 +-
 arch/arm/mach-shark/include/mach/entry-macro.S     |    3 +-
 arch/arm/mach-shark/include/mach/io.h              |   18 ---
 arch/arm/mach-shark/pci.c                          |    5 +
 arch/arm/mach-tegra/include/mach/io.h              |   46 --------
 arch/arm/mach-tegra/include/mach/iomap.h           |    3 +
 arch/arm/mach-tegra/pcie.c                         |   95 ++++-----------
 arch/arm/mach-versatile/core.c                     |    5 -
 arch/arm/mach-versatile/include/mach/hardware.h    |    1 -
 arch/arm/mach-versatile/include/mach/io.h          |   27 -----
 arch/arm/mach-versatile/pci.c                      |   22 +---
 arch/arm/mm/ioremap.c                              |   14 +++
 arch/arm/mm/mmu.c                                  |   54 +++++++--
 arch/arm/plat-iop/pci.c                            |   25 ++--
 arch/arm/plat-iop/setup.c                          |    5 -
 drivers/i2c/busses/i2c-iop3xx.c                    |  121
++++++++++----------
 56 files changed, 414 insertions(+), 910 deletions(-)
 delete mode 100644 arch/arm/mach-dove/include/mach/io.h
 delete mode 100644 arch/arm/mach-integrator/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop32x/include/mach/io.h
 delete mode 100644 arch/arm/mach-iop33x/include/mach/io.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/io.h
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/io.h
 delete mode 100644 arch/arm/mach-orion5x/include/mach/io.h
 delete mode 100644 arch/arm/mach-shark/include/mach/io.h
 delete mode 100644 arch/arm/mach-tegra/include/mach/io.h
 delete mode 100644 arch/arm/mach-versatile/include/mach/io.h

Will Deacon

2012-07-28 14:38 UTC #12 lore raw

Hi Rob,

Quoted 6 lines · Rob Herring

Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console

Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.

I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.

Will

Rob Herring

author

2012-07-30 11:05 UTC #13 lore raw

Quoted 10 lines · Will Deacon

Hi Rob,
Quoted 6 lines · Rob Herring
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console

Quoted 8 lines

Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.
I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.

I did do some tests with qemu by adding i/o setup to integrator/cp. Without it, I would abort on 0xfee003xx (vga regs). Once I added the setup, I got to an abort on a PCI memory address which I did not setup.

We can always revert integrator change if we can figure this out...

Rob

Russell King - ARM Linux

2012-07-30 14:31 UTC #14 lore raw

Quoted 20 lines · Rob Herring

Quoted 10 lines · Will Deacon
Hi Rob,
Quoted 6 lines · Rob Herring
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
Quoted 8 lines
Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.
I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.

Quoted 5 lines

I did do some tests with qemu by adding i/o setup to integrator/cp. Without it, I would abort on 0xfee003xx (vga regs). Once I added the setup, I got to an abort on a PCI memory address which I did not setup.
We can always revert integrator change if we can figure this out...

Err, Integrator/CP doesn't have PCI nor does it have VGA. Only the Integrator/AP has that.

Rob Herring

author

2012-07-30 14:56 UTC #15 lore raw

Quoted 21 lines · Russell King - ARM Linux

Quoted 20 lines · Rob Herring
Quoted 18 lines · Will Deacon
Hi Rob,
Quoted 6 lines · Rob Herring
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.
I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.

Quoted 8 lines

Quoted 5 lines
I did do some tests with qemu by adding i/o setup to integrator/cp. Without it, I would abort on 0xfee003xx (vga regs). Once I added the setup, I got to an abort on a PCI memory address which I did not setup.
We can always revert integrator change if we can figure this out...
Err, Integrator/CP doesn't have PCI nor does it have VGA. Only the Integrator/AP has that.

Yes, I know. But there is no AP model within qemu. I added the mapping to AP and enabled VGA console to do some basic checks that i/o accesses happen. It didn't really have to be integrator platform at all for this test. I know it's not much of a test, but it's something beyond compiling and staring at the code.

I've also tested PCI i/o with versatile under qemu.

Rob

Russell King - ARM Linux

2012-08-27 08:27 UTC #16 lore raw

Quoted 31 lines · Rob Herring

Quoted 21 lines · Russell King - ARM Linux
Quoted 20 lines · Rob Herring
Quoted 18 lines · Will Deacon
Hi Rob,
Quoted 6 lines · Rob Herring
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.
I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.
Quoted 8 lines
Quoted 5 lines
I did do some tests with qemu by adding i/o setup to integrator/cp. Without it, I would abort on 0xfee003xx (vga regs). Once I added the setup, I got to an abort on a PCI memory address which I did not setup.
We can always revert integrator change if we can figure this out...
Err, Integrator/CP doesn't have PCI nor does it have VGA. Only the Integrator/AP has that.

Quoted 7 lines

Yes, I know. But there is no AP model within qemu. I added the mapping to AP and enabled VGA console to do some basic checks that i/o accesses happen. It didn't really have to be integrator platform at all for this test. I know it's not much of a test, but it's something beyond compiling and staring at the code.
I've also tested PCI i/o with versatile under qemu.

What's the conflict resolution for the fix for ioremap of phys 0 (posted by me previously) and your reoganisation and creation of vm_reserve_area_early() ?

Note that I'm taking the autobuilder offline until this is resolved because the tree currently isn't in a buildable state because of this.

Rob Herring

author

2012-08-28 00:14 UTC #17 lore raw

Quoted 38 lines · Russell King - ARM Linux

Quoted 37 lines · Rob Herring
Quoted 21 lines · Russell King - ARM Linux
Quoted 20 lines · Rob Herring
Quoted 18 lines · Will Deacon
Hi Rob,
Quoted 6 lines · Rob Herring
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
Unfortunately, I still experience the same hang on integrator with this revised patch series. Given the turnaround time for testing this, I don't think this should block the series, but I would like to get to the bottom of it if possible.
I tried annotating the PCI code (including fault handlers) and the VGA console code but I couldn't find the culprit. I suppose the next step is JTAG, but that requires steal^Wborrowing some hardware from work.
Quoted 8 lines
Quoted 5 lines
I did do some tests with qemu by adding i/o setup to integrator/cp. Without it, I would abort on 0xfee003xx (vga regs). Once I added the setup, I got to an abort on a PCI memory address which I did not setup.
We can always revert integrator change if we can figure this out...
Err, Integrator/CP doesn't have PCI nor does it have VGA. Only the Integrator/AP has that.
Yes, I know. But there is no AP model within qemu. I added the mapping to AP and enabled VGA console to do some basic checks that i/o accesses happen. It didn't really have to be integrator platform at all for this test. I know it's not much of a test, but it's something beyond compiling and staring at the code.

Quoted 8 lines

Quoted 1 line
I've also tested PCI i/o with versatile under qemu.
What's the conflict resolution for the fix for ioremap of phys 0 (posted by me previously) and your reoganisation and creation of vm_reserve_area_early() ?
Note that I'm taking the autobuilder offline until this is resolved because the tree currently isn't in a buildable state because of this.

I believe you can just replace VM_ARM_STATIC_MAPPING with VM_ARM_EMPTY_MAPPING in vm_reserve_area_early. The pci i/o space and empty sections are the same until pci_ioremap_io is called, and it does not care what the vm flags are.

Rob

Olof Johansson

2012-07-29 23:07 UTC #18 lore raw

In reply to Rob Herring

Hi,

Quoted 23 lines · Rob Herring

Quoted 9 lines · Rob Herring
Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.
Rob
Arnd,
Please pull updated io.h cleanup for PCI branch. I rebased this as the changes shifted things around a bit. This has the following changes:
- Incorporated fixes from you and Stephen
- Add early i/o mapping pci_map_io_early and enable on footbridge and integrator for VGA console
- Avoid including map.h in asm/mach/pci.h which collided with EDAC.
Rob

Quoted 7 lines

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:
Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git io-cleanup-pci-v2

I have replaced the current staging/io-cleanup-pci contents with the above branch. Ideally I'd like to see a fix to the issues on integrator before we send it up though.

-Olof

Will Deacon

Tested-by

2012-08-14 09:14 UTC #19 lore raw

Quoted 5 lines · Olof Johansson

Quoted 5 lines · Rob Herring
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:
Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

Quoted 7 lines

Quoted 3 lines
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git io-cleanup-pci-v2
I have replaced the current staging/io-cleanup-pci contents with the above branch. Ideally I'd like to see a fix to the issues on integrator before we send it up though.

I *finally* got to the bottom of the issues I was seeing on my integrator board with these patches. The ATX PSU I was using doesn't have a thumping great resistor across it and, since the board draws very little current, the voltage is all over the shop. Of the 3 PCI slots, this made one completely unusable, one slightly temperamental and the other `rock solid'.

I was using the temperamental slot and the probing of the VGA console combined with the later PCI initialisation somehow pushes it over the edge and locks up the board. Swapping the PSU for one with an artifical load across it makes all of the slots jump into life.

Late in the day, but I worked for this!:

Tested-by Will Deacon <[email protected]>

Will

Arnd Bergmann

2012-08-14 09:37 UTC #20 lore raw

Quoted 20 lines · Will Deacon

Quoted 5 lines · Olof Johansson
Quoted 5 lines · Rob Herring
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:
Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)
Quoted 7 lines
Quoted 3 lines
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git io-cleanup-pci-v2
I have replaced the current staging/io-cleanup-pci contents with the above branch. Ideally I'd like to see a fix to the issues on integrator before we send it up though.
I finally got to the bottom of the issues I was seeing on my integrator board with these patches. The ATX PSU I was using doesn't have a thumping great resistor across it and, since the board draws very little current, the voltage is all over the shop. Of the 3 PCI slots, this made one completely unusable, one slightly temperamental and the other `rock solid'.

Quoted 8 lines

I was using the temperamental slot and the probing of the VGA console combined with the later PCI initialisation somehow pushes it over the edge and locks up the board. Swapping the PSU for one with an artifical load across it makes all of the slots jump into life.
Late in the day, but I worked for this!:
Tested-by Will Deacon <[email protected]>

Just to let you know, I've started getting the arm-soc tree into shape for v3.7, and the series is now scheduled for integration in the next merge window as a regular branch.

Arnd