Arnd,
Please pull io.h PCI clean-up series. As you suggested, lets get it in
next for test and decide later if to apply it for 3.6 or wait.
BTW, I'll have sporadic email access over the next 2 weeks.
Pulled into staging/io-cleanup-pci, and I added the introductory
text from your patch series as a merge changeset comment.
Thanks for this great series, I hope we can make it for this merge window.
Arnd
Arnd,
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
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 [off-list ref]
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 [off-list ref]
From: Rob Herring <hidden> Date: 2012-07-23 00:35:00
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?
From: Rob Herring <hidden> Date: 2012-07-24 12:33:49
On 07/19/2012 09:12 AM, Arnd Bergmann wrote:
quoted hunk
On Monday 16 July 2012, Rob Herring wrote:
quoted
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
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
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
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
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
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
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>
From: Rob Herring <hidden> Date: 2012-07-27 21:59:18
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
From: Will Deacon <hidden> Date: 2012-07-28 14:38:50
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
From: Olof Johansson <hidden> Date: 2012-07-29 23:07:56
Hi,
On Fri, Jul 27, 2012 at 2:59 PM, Rob Herring [off-list ref] wrote:
On 07/16/2012 05:15 PM, Rob Herring wrote:
quoted
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
From: Rob Herring <hidden> Date: 2012-07-30 11:05:04
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:
quoted
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
From: Russell King - ARM Linux <hidden> Date: 2012-07-30 14:31:19
On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
On 07/28/2012 09:38 AM, Will Deacon wrote:
quoted
Hi Rob,
On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
quoted
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.
From: Rob Herring <hidden> Date: 2012-07-30 14:56:56
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:
quoted
On 07/28/2012 09:38 AM, Will Deacon wrote:
quoted
Hi Rob,
On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
quoted
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
From: Will Deacon <hidden> Date: 2012-08-14 09:14:07
On Mon, Jul 30, 2012 at 12:07:56AM +0100, Olof Johansson wrote:
quoted
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 <redacted>
Will
On Mon, Jul 30, 2012 at 12:07:56AM +0100, Olof Johansson wrote:
quoted
quoted
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 <redacted>
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
From: Russell King - ARM Linux <hidden> Date: 2012-08-27 08:27:55
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:
quoted
On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
quoted
On 07/28/2012 09:38 AM, Will Deacon wrote:
quoted
Hi Rob,
On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
quoted
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.
From: Rob Herring <hidden> Date: 2012-08-28 00:14:12
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:
quoted
On 07/30/2012 09:31 AM, Russell King - ARM Linux wrote:
quoted
On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
quoted
On 07/28/2012 09:38 AM, Will Deacon wrote:
quoted
Hi Rob,
On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
quoted
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