[GIT PULL] io.h clean-up for PCI

[GIT PULL] io.h clean-up for PCI

[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

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

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Monday 16 July 2012, Rob Herring wrote:
> 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

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Monday 16 July 2012, Rob Herring wrote:
> 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 <arnd@arndb.de>

index 9278b8c..cc9e058 100644
--- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
+++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
@@ -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
diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
index 56a4b41..9cad41b 100644
--- a/arch/arm/mach-iop13xx/pci.c
+++ b/arch/arm/mach-iop13xx/pci.c
@@ -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;

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Monday 16 July 2012, Rob Herring wrote:
> 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 <arnd@arndb.de>
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 <arnd@arndb.de>

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 6345a5f..188fd58 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -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);
 }

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/16/2012 05:15 PM, Rob Herring wrote:
> 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?

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 188fd58..78d10a8 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -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)
 {

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/19/2012 09:12 AM, Arnd Bergmann wrote:
> On Monday 16 July 2012, Rob Herring wrote:
>> 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 <arnd@arndb.de>
> 
> index 9278b8c..cc9e058 100644
> --- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> +++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> @@ -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

>  
>  #define IOP13XX_PCIE_MEM_PHYS_OFFSET  	 0x200000000ULL
>  #define IOP13XX_PCIE_MEM_WINDOW_SIZE  	 0x3a000000UL
> diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
> index 56a4b41..9cad41b 100644
> --- a/arch/arm/mach-iop13xx/pci.c
> +++ b/arch/arm/mach-iop13xx/pci.c
> @@ -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;
> 
> 

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Tuesday 24 July 2012, Rob Herring wrote:
> > --- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> > +++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> > @@ -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.

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

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/24/2012 07:43 AM, Arnd Bergmann wrote:
> On Tuesday 24 July 2012, Rob Herring wrote:
>>> --- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
>>> +++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
>>> @@ -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.
> 
> 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.

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

> 
> 	Arnd
> 

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Tuesday 24 July 2012, Rob Herring wrote:
> 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

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/24/2012 07:43 AM, Arnd Bergmann wrote:
> On Tuesday 24 July 2012, Rob Herring wrote:
>>> --- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
>>> +++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
>>> @@ -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.
> 
> 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.

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

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Wednesday 25 July 2012, Rob Herring wrote:
> On 07/24/2012 07:43 AM, Arnd Bergmann wrote:
> > On Tuesday 24 July 2012, Rob Herring wrote:
> >>> --- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> >>> +++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
> >>> @@ -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.
> > 
> > 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.
> 
> 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.

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<----
>From 2012ce83ebbfdee38d2cfc42ab7a8352fe1b95f6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>

diff --git a/arch/arm/mach-iop13xx/include/mach/iop13xx.h b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
index 9278b8c..e10e101 100644
--- a/arch/arm/mach-iop13xx/include/mach/iop13xx.h
+++ b/arch/arm/mach-iop13xx/include/mach/iop13xx.h
@@ -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
diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
index f3826bb..91f731a 100644
--- a/arch/arm/mach-iop13xx/pci.c
+++ b/arch/arm/mach-iop13xx/pci.c
@@ -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;

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/16/2012 05:15 PM, Rob Herring wrote:
> 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

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                    |   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

[GIT PULL] io.h clean-up for PCI

[Will Deacon]

Hi Rob,

On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
> 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

[GIT PULL] io.h clean-up for PCI

[Olof Johansson]

Hi,

On Fri, Jul 27, 2012 at 2:59 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 07/16/2012 05:15 PM, Rob Herring wrote:
>> 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

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

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/28/2012 09:38 AM, Will Deacon wrote:
> Hi Rob,
> 
> On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
>> 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.

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

[GIT PULL] io.h clean-up for PCI

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
> On 07/28/2012 09:38 AM, Will Deacon wrote:
> > Hi Rob,
> > 
> > On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
> >> 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.
> 
> 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.

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 07/30/2012 09:31 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
>> On 07/28/2012 09:38 AM, Will Deacon wrote:
>>> Hi Rob,
>>>
>>> On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
>>>> 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.
>>
>> 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

[GIT PULL] io.h clean-up for PCI

[Will Deacon]

On Mon, Jul 30, 2012 at 12:07:56AM +0100, Olof Johansson wrote:
> > On 07/16/2012 05:15 PM, Rob Herring wrote:
> > 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.

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 <will.deacon@arm.com>

Will

[GIT PULL] io.h clean-up for PCI

[Arnd Bergmann]

On Tuesday 14 August 2012, Will Deacon wrote:
> On Mon, Jul 30, 2012 at 12:07:56AM +0100, Olof Johansson wrote:
> > > On 07/16/2012 05:15 PM, Rob Herring wrote:
> > > 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.
> 
> 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 <will.deacon@arm.com>

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

[GIT PULL] io.h clean-up for PCI

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 09:56:56AM -0500, Rob Herring wrote:
> On 07/30/2012 09:31 AM, Russell King - ARM Linux wrote:
> > On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
> >> On 07/28/2012 09:38 AM, Will Deacon wrote:
> >>> Hi Rob,
> >>>
> >>> On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
> >>>> 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.
> >>
> >> 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.

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.

[GIT PULL] io.h clean-up for PCI

[Rob Herring]

On 08/27/2012 03:27 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 30, 2012 at 09:56:56AM -0500, Rob Herring wrote:
>> On 07/30/2012 09:31 AM, Russell King - ARM Linux wrote:
>>> On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
>>>> On 07/28/2012 09:38 AM, Will Deacon wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
>>>>>> 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.
>>>>
>>>> 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.
> 
> 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