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

login
register
mail settings
Submitter Rob Herring
Date July 16, 2012, 10:15 p.m.
Message ID <50049285.1060100@gmail.com>
Download mbox
Permalink /patch/171280/
State New
Headers show

Pull-request

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

Comments

Rob Herring - July 16, 2012, 10:15 p.m.
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 - July 17, 2012, 8:53 p.m.
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
Rob Herring - July 24, 2012, 12:33 p.m.
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;
> 
>
Arnd Bergmann - July 24, 2012, 12:43 p.m.
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
Rob Herring - July 24, 2012, 1:25 p.m.
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
>
Arnd Bergmann - July 24, 2012, 2:18 p.m.
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
Rob Herring - July 25, 2012, 2:41 p.m.
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