From: Rob Herring <hidden> Date: 2012-07-06 18:40:26
From: Rob Herring <redacted>
This adds a fixed virtual mapping for PCI i/o addresses. The mapping is
located at the last 2MB of vmalloc region (0xfee00000-0xff000000).
Signed-off-by: Rob Herring <redacted>
Cc: Russell King <redacted>
Acked-by: Nicolas Pitre <redacted>
---
Documentation/arm/memory.txt | 3 +++
arch/arm/include/asm/io.h | 5 +++++
arch/arm/include/asm/mach/pci.h | 18 ++++++++++++++++++
arch/arm/kernel/bios32.c | 20 ++++++++++++++++++++
4 files changed, 46 insertions(+)
@@ -51,6 +51,9 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned ff000000 ffbfffff Reserved for future expansion of DMA mapping region.+fee00000 feffffff Mapping of PCI I/O space. This is a static+ mapping within the vmalloc space.+ VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. Memory returned by vmalloc/ioremap will be dynamically placed in this region.
@@ -1,27 +0,0 @@-/*- * arch/arm/mach-versatile/include/mach/io.h- *- * Copyright (C) 2003 ARM Limited- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License as published by- * the Free Software Foundation; either version 2 of the License, or- * (at your option) any later version.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- * You should have received a copy of the GNU General Public License- * along with this program; if not, write to the Free Software- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA- */-#ifndef __ASM_ARM_ARCH_IO_H-#define __ASM_ARM_ARCH_IO_H--#define PCIO_BASE 0xeb000000ul--#define __io(a) ((a) + PCIO_BASE)--#endif
@@ -1,46 +0,0 @@-/*- * arch/arm/mach-tegra/include/mach/io.h- *- * Copyright (C) 2010 Google, Inc.- *- * Author:- * Colin Cross <ccross@google.com>- * Erik Gilling <konkers@google.com>- *- * This software is licensed under the terms of the GNU General Public- * License version 2, as published by the Free Software Foundation, and- * may be copied, distributed, and modified under those terms.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- */--#ifndef __MACH_TEGRA_IO_H-#define __MACH_TEGRA_IO_H--#define IO_SPACE_LIMIT 0xffff--#ifndef __ASSEMBLER__--#ifdef CONFIG_TEGRA_PCI-extern void __iomem *tegra_pcie_io_base;--static inline void __iomem *__io(unsigned long addr)-{- return tegra_pcie_io_base + (addr & IO_SPACE_LIMIT);-}-#else-static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)addr;-}-#endif--#define __io(a) __io(a)--#endif--#endif
@@ -1,33 +0,0 @@-/*- * arch/arm/mach-integrator/include/mach/io.h- *- * Copyright (C) 1999 ARM Limited- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License as published by- * the Free Software Foundation; either version 2 of the License, or- * (at your option) any later version.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- * You should have received a copy of the GNU General Public License- * along with this program; if not, write to the Free Software- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA- */-#ifndef __ASM_ARM_ARCH_IO_H-#define __ASM_ARM_ARCH_IO_H--/*- * WARNING: this has to mirror definitions in platform.h- */-#define PCI_MEMORY_VADDR 0xe8000000-#define PCI_CONFIG_VADDR 0xec000000-#define PCI_V3_VADDR 0xed000000-#define PCI_IO_VADDR 0xee000000--#define __io(a) ((void __iomem *)(PCI_IO_VADDR + (a)))--#endif
From: Rob Herring <hidden> Date: 2012-07-06 18:40:30
From: Rob Herring <redacted>
Convert shark to use the fixed i/o mapping and remove io.h.
This shrinks the mapping from 256MB to 1MB, but nothing is using that much
space AFAICT.
Signed-off-by: Rob Herring <redacted>
Cc: Russell King <redacted>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-shark/core.c | 14 ++------------
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 ------------------
5 files changed, 8 insertions(+), 35 deletions(-)
delete mode 100644 arch/arm/mach-shark/include/mach/io.h
From: Rob Herring <hidden> Date: 2012-07-06 18:40:32
From: Rob Herring <redacted>
The i/o regions are changed from 1MB to 64KB. It's likely that the 2nd
bus is not setup correctly.
Signed-off-by: Rob Herring <redacted>
Acked-by: Nicolas Pitre <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-dove/common.c | 15 +++++----------
arch/arm/mach-dove/include/mach/dove.h | 2 --
arch/arm/mach-dove/include/mach/io.h | 19 -------------------
arch/arm/mach-dove/pcie.c | 9 ++-------
5 files changed, 7 insertions(+), 39 deletions(-)
delete mode 100644 arch/arm/mach-dove/include/mach/io.h
@@ -1,19 +0,0 @@-/*- * arch/arm/mach-dove/include/mach/io.h- *- * This file is licensed under the terms of the GNU General Public- * License version 2. This program is licensed "as is" without any- * warranty of any kind, whether express or implied.- */--#ifndef __ASM_ARCH_IO_H-#define __ASM_ARCH_IO_H--#include "dove.h"--#define IO_SPACE_LIMIT 0xffffffff--#define __io(a) ((void __iomem *)(((a) - DOVE_PCIE0_IO_BUS_BASE) + \- DOVE_PCIE0_IO_VIRT_BASE))--#endif
@@ -1,24 +0,0 @@-/*- * arch/arm/mach-kirkwood/include/mach/io.h- *- * This file is licensed under the terms of the GNU General Public- * License version 2. This program is licensed "as is" without any- * warranty of any kind, whether express or implied.- */--#ifndef __ASM_ARCH_IO_H-#define __ASM_ARCH_IO_H--#include "kirkwood.h"--#define IO_SPACE_LIMIT 0xffffffff--static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)((addr - KIRKWOOD_PCIE_IO_BUS_BASE)- + KIRKWOOD_PCIE_IO_VIRT_BASE);-}--#define __io(a) __io(a)--#endif
@@ -1,22 +0,0 @@-/*- * arch/arm/mach-orion5x/include/mach/io.h- *- * This file is licensed under the terms of the GNU General Public- * License version 2. This program is licensed "as is" without any- * warranty of any kind, whether express or implied.- */--#ifndef __ASM_ARCH_IO_H-#define __ASM_ARCH_IO_H--#include <mach/orion5x.h>-#include <asm/sizes.h>--#define IO_SPACE_LIMIT SZ_2M-static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)(addr + ORION5X_PCIE_IO_VIRT_BASE);-}--#define __io(a) __io(a)-#endif
From: Rob Herring <hidden> Date: 2012-07-06 18:40:35
From: Arnd Bergmann <arnd@arndb.de>
iop13xx confuses I/O port numbers with physical addresses, which breaks
legacy ISA I/O access behind PCI bridges and makes it unnecessarily hard
to unify the inb/outb accessors with other platforms. This removes the
special-casing and just puts all I/O ports into a single 128KB virtually
mapped I/O port range starting at port zero.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-iop13xx/include/mach/io.h | 6 +++---
arch/arm/mach-iop13xx/include/mach/iop13xx.h | 12 +++---------
arch/arm/mach-iop13xx/io.c | 27 --------------------------
arch/arm/mach-iop13xx/pci.c | 12 ++++++------
4 files changed, 12 insertions(+), 45 deletions(-)
@@ -1052,7 +1052,7 @@ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys)res[1].name="IQ81340 ATUX PCI Memory Space";res[1].flags=IORESOURCE_MEM;sys->mem_offset=IOP13XX_PCIX_MEM_OFFSET;-sys->io_offset=IOP13XX_PCIX_LOWER_IO_PA;+sys->io_offset=IOP13XX_PCIX_LOWER_IO_BA;break;caseIOP13XX_INIT_ATU_ATUE:/* Note: the function number field in the PCSR is ro */
@@ -1,28 +0,0 @@-/*- * iop13xx custom ioremap implementation- * Copyright (c) 2005-2006, Intel Corporation.- *- * This program is free software; you can redistribute it and/or modify it- * under the terms and conditions of the GNU General Public License,- * version 2, as published by the Free Software Foundation.- *- * This program is distributed in the hope it will be useful, but WITHOUT- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for- * more details.- *- * You should have received a copy of the GNU General Public License along with- * this program; if not, write to the Free Software Foundation, Inc., 59 Temple- * Place - Suite 330, Boston, MA 02111-1307 USA.- *- */-#ifndef __ASM_ARM_ARCH_IO_H-#define __ASM_ARM_ARCH_IO_H--#include <mach/iop13xx.h>--#define IO_SPACE_LIMIT (IOP13XX_PCIE_IO_WINDOW_SIZE + IOP13XX_PCIX_IO_WINDOW_SIZE - 1)--#define __io(a) (IOP13XX_PCIX_LOWER_IO_VA + ((a) & IO_SPACE_LIMIT))--#endif
From: Rob Herring <hidden> Date: 2012-07-06 18:40:37
From: Rob Herring <redacted>
Move mv78xx0 PCI to fixed i/o mapping and remove io.h. This changes the PCI
bus addresses from the cpu address to 0 based. It appears that there is
translation h/w for this, but its untested.
Signed-off-by: Rob Herring <redacted>
Cc: Jason Cooper <redacted>
Cc: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-mv78xx0/addr-map.c | 1 +
arch/arm/mach-mv78xx0/common.c | 18 ++++++++++++-----
arch/arm/mach-mv78xx0/include/mach/io.h | 24 ----------------------
arch/arm/mach-mv78xx0/include/mach/mv78xx0.h | 22 +++++++++-----------
arch/arm/mach-mv78xx0/pcie.c | 28 +++++---------------------
6 files changed, 29 insertions(+), 65 deletions(-)
delete mode 100644 arch/arm/mach-mv78xx0/include/mach/io.h
@@ -1,24 +0,0 @@-/*- * arch/arm/mach-mv78xx0/include/mach/io.h- *- * This file is licensed under the terms of the GNU General Public- * License version 2. This program is licensed "as is" without any- * warranty of any kind, whether express or implied.- */--#ifndef __ASM_ARCH_IO_H-#define __ASM_ARCH_IO_H--#include "mv78xx0.h"--#define IO_SPACE_LIMIT 0xffffffff--static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)((addr - MV78XX0_PCIE_IO_PHYS_BASE(0))- + MV78XX0_PCIE_IO_VIRT_BASE(0));-}--#define __io(a) __io(a)--#endif
@@ -45,8 +45,8 @@/* global unit counter */staticinti2c_id;-staticinlineunsignedchar-iic_cook_addr(structi2c_msg*msg)+staticinlineunsignedchar+iic_cook_addr(structi2c_msg*msg){unsignedcharaddr;
@@ -86,7 +86,7 @@ iop3xx_i2c_enable(struct i2c_algo_iop3xx_data *iop3xx_adap)}#endif/* NB SR bits not same position as CR IE bits :-( */-iop3xx_adap->SR_enabled=+iop3xx_adap->SR_enabled=IOP3XX_ISR_ALD|IOP3XX_ISR_BERRD|IOP3XX_ISR_RXFULL|IOP3XX_ISR_TXEMPTY;
@@ -126,7 +126,7 @@ iop3xx_i2c_irq_handler(int this_irq, void *dev_id)}/* check all error conditions, clear them , report most important */-staticint+staticintiop3xx_i2c_error(u32sr){intrc=0;
From: Rob Herring <hidden> Date: 2012-07-06 18:40:39
From: Rob Herring <redacted>
Instead of using the custom iop3xx gpio functions, use the gpiolib
variants. This should be functionally the same since the gpiolib
just calls the iop3xx gpio functions. This is needed in preparation
of removing iop3xx mach/io.h headers.
Signed-off-by: Rob Herring <redacted>
Cc: "Jean Delvare (PC drivers, core)" <redacted>
Cc: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
Cc: "Wolfram Sang (embedded platforms)" <redacted>
Cc: linux-i2c at vger.kernel.org
---
drivers/i2c/busses/i2c-iop3xx.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
@@ -78,11 +79,11 @@ iop3xx_i2c_enable(struct i2c_algo_iop3xx_data *iop3xx_adap)*/#if defined(CONFIG_ARCH_IOP32X) || defined(CONFIG_ARCH_IOP33X)if(iop3xx_adap->id==0){-gpio_line_set(IOP3XX_GPIO_LINE(7),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(6),GPIO_LOW);+gpio_set_value(7,0);+gpio_set_value(6,0);}else{-gpio_line_set(IOP3XX_GPIO_LINE(5),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(4),GPIO_LOW);+gpio_set_value(5,0);+gpio_set_value(4,0);}#endif/* NB SR bits not same position as CR IE bits :-( */
From: Rob Herring <hidden> Date: 2012-07-06 18:40:40
From: Rob Herring <redacted>
Move iop33x and iop32x PCI to fixed i/o mapping and remove io.h. This
changes the PCI bus addresses from the cpu address to 0 based. It appears
that there is translation h/w for this, but its untested.
Not sure what to do with io_offset. I think it should always be 0.
AFAICT, PCI setup is skipped if the ATU is already setup.
Signed-off-by: Rob Herring <redacted>
---
arch/arm/Kconfig | 2 --
arch/arm/include/asm/hardware/iop3xx.h | 12 +-----------
arch/arm/mach-iop32x/include/mach/io.h | 19 -------------------
arch/arm/mach-iop33x/include/mach/io.h | 19 -------------------
arch/arm/plat-iop/pci.c | 4 ++--
arch/arm/plat-iop/setup.c | 7 ++-----
6 files changed, 5 insertions(+), 58 deletions(-)
delete mode 100644 arch/arm/mach-iop32x/include/mach/io.h
delete mode 100644 arch/arm/mach-iop33x/include/mach/io.h
@@ -1,19 +0,0 @@-/*- * arch/arm/mach-iop32x/include/mach/io.h- *- * Copyright (C) 2001 MontaVista Software, Inc.- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License version 2 as- * published by the Free Software Foundation.- */--#ifndef __IO_H-#define __IO_H--#include <asm/hardware/iop3xx.h>--#define IO_SPACE_LIMIT 0xffffffff-#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))--#endif
@@ -1,19 +0,0 @@-/*- * arch/arm/mach-iop33x/include/mach/io.h- *- * Copyright (C) 2001 MontaVista Software, Inc.- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License version 2 as- * published by the Free Software Foundation.- */--#ifndef __IO_H-#define __IO_H--#include <asm/hardware/iop3xx.h>--#define IO_SPACE_LIMIT 0xffffffff-#define __io(p) ((void __iomem *)IOP3XX_PCI_IO_PHYS_TO_VIRT(p))--#endif
From: Stephen Warren <hidden> Date: 2012-07-06 19:44:40
On 07/06/2012 12:40 PM, Rob Herring wrote:
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Thierry, since you're the Tegra PCIe expert right now, could you please
test and/or comment on this.
I did try testing this on next-20120705 on TrimSlice (i.e. the
PCIe-based Ethernet controller), but found that PCIe has stopped working
there due to "resource collisions". I know this used to work fairly
recently, since I tested it when I added the PCIe initialization call to
board-dt-tegra20.c. The PCIe messages are:
PCIE: port 1: link down, retrying
PCIE: port 1: link down, retrying
PCIE: port 1: link down, ignoring
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x8fff]
pci_bus 0000:00: root bus resource [mem 0x90000000-0x97ffffff]
pci_bus 0000:00: root bus resource [mem 0xa0000000-0xa7ffffff pref]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]
pci 0000:00:00.0: [10de:0bf0] type 01 class 0x060000
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCI: bus0: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] is inserted under [bus 00-ff]
pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000
pci 0000:01:00.0: reg 10: [io 0x0000-0x00ff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff 64bit pref]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00003fff 64bit pref]
pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
PCI: Device 0000:01:00.0 not available because of resource collisions
r8169 0000:01:00.0: (unregistered net_device): enable failure
r8169: probe of 0000:01:00.0 failed with error -22
pci 0000:00:00.0: BAR 9: assigned [mem 0xa0000000-0xa00fffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 6: assigned [mem 0xa0000000-0xa001ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xa0020000-0xa0023fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xa0024000-0xa0024fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xa00fffff pref]
PCI: enabling device 0000:00:00.0 (0140 -> 0143)
From: Rob Herring <hidden> Date: 2012-07-06 20:11:53
On 07/06/2012 02:44 PM, Stephen Warren wrote:
On 07/06/2012 12:40 PM, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Thierry, since you're the Tegra PCIe expert right now, could you please
test and/or comment on this.
I did try testing this on next-20120705 on TrimSlice (i.e. the
PCIe-based Ethernet controller), but found that PCIe has stopped working
there due to "resource collisions". I know this used to work fairly
recently, since I tested it when I added the PCIe initialization call to
board-dt-tegra20.c. The PCIe messages are:
This is with my change and it works currently without?
The i/o mapping of the 2nd ctrlr looked a bit screwy to me. It's not
clear to me how an i/o address of 0x11000+ gets steered to the 2nd
controller.
Rob
quoted
PCIE: port 1: link down, retrying
PCIE: port 1: link down, retrying
PCIE: port 1: link down, ignoring
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x8fff]
pci_bus 0000:00: root bus resource [mem 0x90000000-0x97ffffff]
pci_bus 0000:00: root bus resource [mem 0xa0000000-0xa7ffffff pref]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]
pci 0000:00:00.0: [10de:0bf0] type 01 class 0x060000
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCI: bus0: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] is inserted under [bus 00-ff]
pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000
pci 0000:01:00.0: reg 10: [io 0x0000-0x00ff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff 64bit pref]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00003fff 64bit pref]
pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
PCI: Device 0000:01:00.0 not available because of resource collisions
r8169 0000:01:00.0: (unregistered net_device): enable failure
r8169: probe of 0000:01:00.0 failed with error -22
pci 0000:00:00.0: BAR 9: assigned [mem 0xa0000000-0xa00fffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 6: assigned [mem 0xa0000000-0xa001ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xa0020000-0xa0023fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xa0024000-0xa0024fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xa00fffff pref]
PCI: enabling device 0000:00:00.0 (0140 -> 0143)
From: Stephen Warren <hidden> Date: 2012-07-06 20:16:09
On 07/06/2012 02:11 PM, Rob Herring wrote:
On 07/06/2012 02:44 PM, Stephen Warren wrote:
quoted
On 07/06/2012 12:40 PM, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Thierry, since you're the Tegra PCIe expert right now, could you please
test and/or comment on this.
I did try testing this on next-20120705 on TrimSlice (i.e. the
PCIe-based Ethernet controller), but found that PCIe has stopped working
there due to "resource collisions". I know this used to work fairly
recently, since I tested it when I added the PCIe initialization call to
board-dt-tegra20.c. The PCIe messages are:
This is with my change and it works currently without?
Sorry, no, it's broken even without your change. Hence, I can't test the
impact of your change. Well, I saw the same failure with your patches
too, but that isn't really conclusive testing of your change:-)
From: Stephen Warren <hidden> Date: 2012-07-06 20:36:49
On 07/06/2012 02:16 PM, Stephen Warren wrote:
On 07/06/2012 02:11 PM, Rob Herring wrote:
quoted
On 07/06/2012 02:44 PM, Stephen Warren wrote:
quoted
On 07/06/2012 12:40 PM, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Thierry, since you're the Tegra PCIe expert right now, could you please
test and/or comment on this.
I did try testing this on next-20120705 on TrimSlice (i.e. the
PCIe-based Ethernet controller), but found that PCIe has stopped working
there due to "resource collisions". I know this used to work fairly
recently, since I tested it when I added the PCIe initialization call to
board-dt-tegra20.c. The PCIe messages are:
This is with my change and it works currently without?
Sorry, no, it's broken even without your change. Hence, I can't test the
impact of your change. Well, I saw the same failure with your patches
too, but that isn't really conclusive testing of your change:-)
Aha. The PCIe problem only shows up when booting TrimSlice using DT (in
next-20120705 or Tegra's for-next branch).
When booting using board files, PCIe works, both without and with your
patch, on top of next-20120705.
So, your patches are tested on Tegra and still working.
From: Stephen Warren <hidden> Date: 2012-07-06 21:01:41
(cutting down CCs for Tegra-specific discussion)
On 07/06/2012 02:36 PM, Stephen Warren wrote:
On 07/06/2012 02:16 PM, Stephen Warren wrote:
quoted
On 07/06/2012 02:11 PM, Rob Herring wrote:
quoted
On 07/06/2012 02:44 PM, Stephen Warren wrote:
quoted
On 07/06/2012 12:40 PM, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Thierry, since you're the Tegra PCIe expert right now, could you please
test and/or comment on this.
I did try testing this on next-20120705 on TrimSlice (i.e. the
PCIe-based Ethernet controller), but found that PCIe has stopped working
there due to "resource collisions". I know this used to work fairly
recently, since I tested it when I added the PCIe initialization call to
board-dt-tegra20.c. The PCIe messages are:
This is with my change and it works currently without?
Sorry, no, it's broken even without your change. Hence, I can't test the
impact of your change. Well, I saw the same failure with your patches
too, but that isn't really conclusive testing of your change:-)
Aha. The PCIe problem only shows up when booting TrimSlice using DT (in
next-20120705 or Tegra's for-next branch).
When booting using board files, PCIe works, both without and with your
patch, on top of next-20120705.
So, your patches are tested on Tegra and still working.
I haven't root-caused it, but I have found what changed that triggered
the problem:
When I first wrote the patch to board-dt-tegra20.c that brought DT
booting up to feature parity with non-DT boot, IIRC, I wrote a
late_initcall() to run whatever code I added. I'm sure I tested
TrimSlice PCIe when booting using DT then, since that was the whole
point of the patch.
Later, I revised the patch to sit on top of Shawn Guo's .init_late
machine descriptor patch, and ran the code from there instead. However,
this appears to have broken PCIe on Trimslice; I must have screwed up
the testing of that change. I don't know why this causes a behavior
difference though; perhaps some resource acquisition race condition.
But just reverting that change doesn't fix the problem; I need to switch
to a *subsys*_initcall() instead (which is in fact what the Trimslice
board file uses for PCIe init). In other words:
On Fri, Jul 06, 2012 at 01:40:28PM -0500, Rob Herring wrote:
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Signed-off-by: Rob Herring <redacted>
Cc: Colin Cross <redacted>
Cc: Olof Johansson <redacted>
Acked-by: Stephen Warren <redacted>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-tegra/include/mach/io.h | 46 ------------------------------
arch/arm/mach-tegra/include/mach/iomap.h | 3 ++
arch/arm/mach-tegra/io.c | 2 ++
arch/arm/mach-tegra/pcie.c | 43 ++++------------------------
5 files changed, 10 insertions(+), 85 deletions(-)
delete mode 100644 arch/arm/mach-tegra/include/mach/io.h
Hi Rob,
generally this looks good. However I've been working on a rewrite of the
Tegra PCIe support to make it work as a driver and add DT support. This
entails that PCIe support isn't initialized until very late in the
process because it makes use of deferred probe if some regulators aren't
available. One problem caused by this is that it suddenly requires a lot
of code marked as __init to be available after the init phase and I see
that you've introduced pci_map_io_single_pfn() that is __init annotated,
so it will cause problems when used with my patches.
I'm not very familiar with the inner workings of the iotable and the
mappings initialized by it, but I wonder if this can be done dynamically
at a later stage. The way this is currently done in this patch, the I/O
region is statically mapped from a fixed offset within the PCIe address
range. Part of the patches to add DT support is to allow this region to
be defined by the DT, so that will obviously also create problems.
If both of those issues can be easily addressed, then this certainly
looks very nice.
Thierry
@@ -1,46 +0,0 @@-/*- * arch/arm/mach-tegra/include/mach/io.h- *- * Copyright (C) 2010 Google, Inc.- *- * Author:- * Colin Cross <ccross@google.com>- * Erik Gilling <konkers@google.com>- *- * This software is licensed under the terms of the GNU General Public- * License version 2, as published by the Free Software Foundation, and- * may be copied, distributed, and modified under those terms.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- */--#ifndef __MACH_TEGRA_IO_H-#define __MACH_TEGRA_IO_H--#define IO_SPACE_LIMIT 0xffff--#ifndef __ASSEMBLER__--#ifdef CONFIG_TEGRA_PCI-extern void __iomem *tegra_pcie_io_base;--static inline void __iomem *__io(unsigned long addr)-{- return tegra_pcie_io_base + (addr & IO_SPACE_LIMIT);-}-#else-static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)addr;-}-#endif--#define __io(a) __io(a)--#endif--#endif
From: Wolfram Sang <hidden> Date: 2012-07-08 11:29:03
On Fri, Jul 06, 2012 at 01:40:39PM -0500, Rob Herring wrote:
From: Rob Herring <redacted>
Instead of using the custom iop3xx gpio functions, use the gpiolib
variants. This should be functionally the same since the gpiolib
just calls the iop3xx gpio functions. This is needed in preparation
of removing iop3xx mach/io.h headers.
Signed-off-by: Rob Herring <redacted>
Cc: "Jean Delvare (PC drivers, core)" <redacted>
Cc: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
Cc: "Wolfram Sang (embedded platforms)" <redacted>
Cc: linux-i2c at vger.kernel.org
Is this dependent on another patch from this series? Or can this go
via the I2C tree? I am fine with just acking this one, but the
whitespace removal should better go via I2C I think.
Thanks,
Wolfram
@@ -78,11 +79,11 @@ iop3xx_i2c_enable(struct i2c_algo_iop3xx_data *iop3xx_adap)*/#if defined(CONFIG_ARCH_IOP32X) || defined(CONFIG_ARCH_IOP33X)if(iop3xx_adap->id==0){-gpio_line_set(IOP3XX_GPIO_LINE(7),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(6),GPIO_LOW);+gpio_set_value(7,0);+gpio_set_value(6,0);}else{-gpio_line_set(IOP3XX_GPIO_LINE(5),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(4),GPIO_LOW);+gpio_set_value(5,0);+gpio_set_value(4,0);}#endif/* NB SR bits not same position as CR IE bits :-( */
From: Rob Herring <hidden> Date: 2012-07-08 14:17:44
On 07/08/2012 01:09 AM, Thierry Reding wrote:
On Fri, Jul 06, 2012 at 01:40:28PM -0500, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Move tegra PCI to fixed i/o mapping and remove io.h.
Signed-off-by: Rob Herring <redacted>
Cc: Colin Cross <redacted>
Cc: Olof Johansson <redacted>
Acked-by: Stephen Warren <redacted>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-tegra/include/mach/io.h | 46 ------------------------------
arch/arm/mach-tegra/include/mach/iomap.h | 3 ++
arch/arm/mach-tegra/io.c | 2 ++
arch/arm/mach-tegra/pcie.c | 43 ++++------------------------
5 files changed, 10 insertions(+), 85 deletions(-)
delete mode 100644 arch/arm/mach-tegra/include/mach/io.h
Hi Rob,
generally this looks good. However I've been working on a rewrite of the
Tegra PCIe support to make it work as a driver and add DT support. This
entails that PCIe support isn't initialized until very late in the
process because it makes use of deferred probe if some regulators aren't
available. One problem caused by this is that it suddenly requires a lot
of code marked as __init to be available after the init phase and I see
that you've introduced pci_map_io_single_pfn() that is __init annotated,
so it will cause problems when used with my patches.
This function can only be called during .map_io anyway, so the __init is
irrelevant.
I'm not very familiar with the inner workings of the iotable and the
mappings initialized by it, but I wonder if this can be done dynamically
at a later stage. The way this is currently done in this patch, the I/O
region is statically mapped from a fixed offset within the PCIe address
range. Part of the patches to add DT support is to allow this region to
be defined by the DT, so that will obviously also create problems.
Is the i/o address something you could extract from DT earlier? This can
be done separately if it doesn't require information from the driver.
I'm sure exactly how to do a fixed virtual mapping other than the
io_table mappings. There was some discussion of use fixmap region
previously, but doing so will be a bit more complex. I'll look into this
some.
Rob
If both of those issues can be easily addressed, then this certainly
looks very nice.
Thierry
@@ -1,46 +0,0 @@-/*- * arch/arm/mach-tegra/include/mach/io.h- *- * Copyright (C) 2010 Google, Inc.- *- * Author:- * Colin Cross <ccross@google.com>- * Erik Gilling <konkers@google.com>- *- * This software is licensed under the terms of the GNU General Public- * License version 2, as published by the Free Software Foundation, and- * may be copied, distributed, and modified under those terms.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- */--#ifndef __MACH_TEGRA_IO_H-#define __MACH_TEGRA_IO_H--#define IO_SPACE_LIMIT 0xffff--#ifndef __ASSEMBLER__--#ifdef CONFIG_TEGRA_PCI-extern void __iomem *tegra_pcie_io_base;--static inline void __iomem *__io(unsigned long addr)-{- return tegra_pcie_io_base + (addr & IO_SPACE_LIMIT);-}-#else-static inline void __iomem *__io(unsigned long addr)-{- return (void __iomem *)addr;-}-#endif--#define __io(a) __io(a)--#endif--#endif
From: Rob Herring <hidden> Date: 2012-07-08 14:29:28
On 07/08/2012 06:29 AM, Wolfram Sang wrote:
On Fri, Jul 06, 2012 at 01:40:39PM -0500, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
Instead of using the custom iop3xx gpio functions, use the gpiolib
variants. This should be functionally the same since the gpiolib
just calls the iop3xx gpio functions. This is needed in preparation
of removing iop3xx mach/io.h headers.
Signed-off-by: Rob Herring <redacted>
Cc: "Jean Delvare (PC drivers, core)" <redacted>
Cc: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
Cc: "Wolfram Sang (embedded platforms)" <redacted>
Cc: linux-i2c at vger.kernel.org
Is this dependent on another patch from this series? Or can this go
via the I2C tree? I am fine with just acking this one, but the
whitespace removal should better go via I2C I think.
They can go in via i2c tree. The rest probably won't make 3.6.
Rob
@@ -78,11 +79,11 @@ iop3xx_i2c_enable(struct i2c_algo_iop3xx_data *iop3xx_adap)*/#if defined(CONFIG_ARCH_IOP32X) || defined(CONFIG_ARCH_IOP33X)if(iop3xx_adap->id==0){-gpio_line_set(IOP3XX_GPIO_LINE(7),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(6),GPIO_LOW);+gpio_set_value(7,0);+gpio_set_value(6,0);}else{-gpio_line_set(IOP3XX_GPIO_LINE(5),GPIO_LOW);-gpio_line_set(IOP3XX_GPIO_LINE(4),GPIO_LOW);+gpio_set_value(5,0);+gpio_set_value(4,0);}#endif/* NB SR bits not same position as CR IE bits :-( */
I'm not very familiar with the inner workings of the iotable and the
mappings initialized by it, but I wonder if this can be done dynamically
at a later stage. The way this is currently done in this patch, the I/O
region is statically mapped from a fixed offset within the PCIe address
range. Part of the patches to add DT support is to allow this region to
be defined by the DT, so that will obviously also create problems.
Is the i/o address something you could extract from DT earlier? This can
be done separately if it doesn't require information from the driver.
I'm sure exactly how to do a fixed virtual mapping other than the
io_table mappings. There was some discussion of use fixmap region
previously, but doing so will be a bit more complex. I'll look into this
some.
I think you can call ioremap_page_range() to do this.
Arnd
From: Rob Herring <hidden> Date: 2012-07-08 20:33:23
On 07/08/2012 11:35 AM, Arnd Bergmann wrote:
On Sunday 08 July 2012, Rob Herring wrote:
quoted
quoted
I'm not very familiar with the inner workings of the iotable and the
mappings initialized by it, but I wonder if this can be done dynamically
at a later stage. The way this is currently done in this patch, the I/O
region is statically mapped from a fixed offset within the PCIe address
range. Part of the patches to add DT support is to allow this region to
be defined by the DT, so that will obviously also create problems.
Is the i/o address something you could extract from DT earlier? This can
be done separately if it doesn't require information from the driver.
I'm sure exactly how to do a fixed virtual mapping other than the
io_table mappings. There was some discussion of use fixmap region
previously, but doing so will be a bit more complex. I'll look into this
some.
I think you can call ioremap_page_range() to do this.
Thanks for the pointer. But this has to be in 2 steps. First reserve the
virtual space and then map it. For the first part I think something like
this function will work:
void __init pci_reserve_io(void)
{
struct vm_struct *vm;
vm = early_alloc_aligned(sizeof(*vm), __alignof__(*vm));
vm->addr = (void *)PCI_IO_VIRT_BASE;
vm->size = SZ_1M;
vm->phys_addr = 0;
vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
vm->flags |= VM_ARM_MTYPE(MT_DEVICE);
vm->caller = pci_reserve_io;
vm_area_add_early(vm++);
}
There's a big fat warning on vm_area_add_early from Nico to not use
unless you know what you're doing. I'll pretend I do...
Rob
I'm not very familiar with the inner workings of the iotable and the
mappings initialized by it, but I wonder if this can be done dynamically
at a later stage. The way this is currently done in this patch, the I/O
region is statically mapped from a fixed offset within the PCIe address
range. Part of the patches to add DT support is to allow this region to
be defined by the DT, so that will obviously also create problems.
Is the i/o address something you could extract from DT earlier? This can
be done separately if it doesn't require information from the driver.
I'm sure exactly how to do a fixed virtual mapping other than the
io_table mappings. There was some discussion of use fixmap region
previously, but doing so will be a bit more complex. I'll look into this
some.
I think you can call ioremap_page_range() to do this.
Thanks for the pointer. But this has to be in 2 steps. First reserve the
virtual space and then map it. For the first part I think something like
this function will work:
void __init pci_reserve_io(void)
{
struct vm_struct *vm;
vm = early_alloc_aligned(sizeof(*vm), __alignof__(*vm));
vm->addr = (void *)PCI_IO_VIRT_BASE;
vm->size = SZ_1M;
vm->phys_addr = 0;
vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
vm->flags |= VM_ARM_MTYPE(MT_DEVICE);
vm->caller = pci_reserve_io;
vm_area_add_early(vm++);
}
There's a big fat warning on vm_area_add_early from Nico to not use
unless you know what you're doing. I'll pretend I do...
:-)
This warning was inherited from vm_area_register_early() which used to
make the core of what vm_area_add_early() is today.
Your usage of vm_area_add_early() should be fine as long as it is done
before vmalloc_init(() is called.
Nicolas
/*
+ * Setup fixed I/O mapping. Must be called from .map_io function.
+ */
+#ifdef CONFIG_PCI
+extern void pci_map_io_pfn(unsigned long pfn[], int nr, int size);
+#else
+static inline void pci_map_io_pfn(unsigned long pfn[], int nr, int size) {}
+#endif
+static inline void __init pci_map_io_single_pfn(unsigned long pfn)
+{
+ pci_map_io_pfn(&pfn, 1, SZ_1M);
+}
+
+static inline void __init pci_map_io_single(unsigned long paddr)
+{
+ pci_map_io_single_pfn(__phys_to_pfn(paddr));
+}
On powerpc, we have a special flag that gets used to register a "primary"
I/O space, which is the one that holds the port numbers between 0 and 1024
because that is the only place that an ISA add-on card can be used in.
I wonder if we want to support that as well, or if we just assume that
the first one to get registered is the primary bus.
Arnd
From: Rob Herring <redacted>
I've finally gotten back to this after several months. This is the 2nd
part of mach/io.h removals. This series removes io.h on platforms with
PCI by creating a fixed virtual I/O mapping and a common __io() macro.
As several platforms have 2 1MB I/O windows, I've changed the fixed
mapping to 2MB (vs. 1MB in the prior posting) and allow platforms to
control the size. This also allows using a single 1MB section mapping
rather than 4KB pages.
Looks really good, feel free to add my Reviewed-by on patches 2-15, since
I've done a line-by-line walkthrough and could not find anything besides the
trivial comments I gave.
I've only tested versatilepb under qemu, so any testing is appreciated.
iop3xx and mv78xx0 have some risk of breaking as the PCI bus addresses
are moved to 0 from matching the cpu host bus addesss.
Did you try running any devices that actually use I/O space in qemu?
I think there are plenty of devices that you could use for testing that.
Arnd
Why use SZ_64K here when the mapping is actually 1M?
Why use 1M when 64K is enough based on our prior conversations? The more
we standardize the configuration, the more we can make common. I think
the majority of the pci setup functions can be consolidated. It's really
just data differences for the resource setup. I only used 1M alignment
in case there were some alignment requirements in the h/w and it can't
handle a starting pci bus address of 0x10000. I think it's just the
Marvell parts that do this, so if anyone knowledgeable on those parts
can comment it would help.
Rob
From: Rob Herring <hidden> Date: 2012-07-09 18:42:06
On 07/09/2012 11:28 AM, Arnd Bergmann wrote:
On Friday 06 July 2012, Rob Herring wrote:
quoted
From: Rob Herring <redacted>
I've finally gotten back to this after several months. This is the 2nd
part of mach/io.h removals. This series removes io.h on platforms with
PCI by creating a fixed virtual I/O mapping and a common __io() macro.
As several platforms have 2 1MB I/O windows, I've changed the fixed
mapping to 2MB (vs. 1MB in the prior posting) and allow platforms to
control the size. This also allows using a single 1MB section mapping
rather than 4KB pages.
Looks really good, feel free to add my Reviewed-by on patches 2-15, since
I've done a line-by-line walkthrough and could not find anything besides the
trivial comments I gave.
Thanks for the review. It's going to change a bit with using
ioremap_page_range. Hope to have new version out soon.
quoted
I've only tested versatilepb under qemu, so any testing is appreciated.
iop3xx and mv78xx0 have some risk of breaking as the PCI bus addresses
are moved to 0 from matching the cpu host bus addesss.
Did you try running any devices that actually use I/O space in qemu?
I think there are plenty of devices that you could use for testing that.
I had with sym53c8xx, but it defaulted to memory accesses. Now that I
enable i/o access mode, it fails due to pcibios_min_io = 0x44000000.
With that removed it gets into the driver setup but then fails (with or
without my changes). Might be a qemu model issue. I'll try some other
devices.
Rob
From: Rob Herring <redacted>
I've finally gotten back to this after several months. This is the 2nd
part of mach/io.h removals. This series removes io.h on platforms with
PCI by creating a fixed virtual I/O mapping and a common __io() macro.
As several platforms have 2 1MB I/O windows, I've changed the fixed
mapping to 2MB (vs. 1MB in the prior posting) and allow platforms to
control the size. This also allows using a single 1MB section mapping
rather than 4KB pages.
Looks really good, feel free to add my Reviewed-by on patches 2-15, since
I've done a line-by-line walkthrough and could not find anything besides the
trivial comments I gave.
Thanks for the review. It's going to change a bit with using
ioremap_page_range. Hope to have new version out soon.
Beware the fact that you can't use ioremap_page_range() early on during
the boot as it uses the standard page allocator.
Nicolas
Why use 1M when 64K is enough based on our prior conversations? The more
we standardize the configuration, the more we can make common. I think
the majority of the pci setup functions can be consolidated. It's really
just data differences for the resource setup. I only used 1M alignment
in case there were some alignment requirements in the h/w and it can't
handle a starting pci bus address of 0x10000. I think it's just the
Marvell parts that do this, so if anyone knowledgeable on those parts
can comment it would help.
IIRC among the plat-orion platforms (dove, kirkwood, mv78xx0, orion), this
one is the only one where you use 64kb in the resource but 1MB for the
mapping, while in the other ones they are always the same. I agree that
the 64kb resource doesn't hurt, we should just be more consistent.
Arnd
Why use 1M when 64K is enough based on our prior conversations? The more
we standardize the configuration, the more we can make common. I think
the majority of the pci setup functions can be consolidated. It's really
just data differences for the resource setup. I only used 1M alignment
in case there were some alignment requirements in the h/w and it can't
handle a starting pci bus address of 0x10000. I think it's just the
Marvell parts that do this, so if anyone knowledgeable on those parts
can comment it would help.
The only Marvell board I have which can accommodate a PCI card does
support 3.3V PCI cards only. Otherwise this is all PCI Express. And
the only PCI cards with I/O space I've seen are 5V PCI cards.
So I'd say: go for the option with the best consolidation outcome. No
one is using cards with I/O space on those platforms.
Nicolas
Why use 1M when 64K is enough based on our prior conversations? The more
we standardize the configuration, the more we can make common. I think
the majority of the pci setup functions can be consolidated. It's really
just data differences for the resource setup. I only used 1M alignment
in case there were some alignment requirements in the h/w and it can't
handle a starting pci bus address of 0x10000. I think it's just the
Marvell parts that do this, so if anyone knowledgeable on those parts
can comment it would help.
The only Marvell board I have which can accommodate a PCI card does
support 3.3V PCI cards only. Otherwise this is all PCI Express. And
the only PCI cards with I/O space I've seen are 5V PCI cards.
All graphics cards and ATA controllers support backwards compatible PIO
access to the VGA or IDE registers, and they are available for PCI express.
A lot of PCIe legacy I/O cards (uart, printer, GPIO) can also use PIO
mode to be backwards compatible.
So I'd say: go for the option with the best consolidation outcome. No
one is using cards with I/O space on those platforms.