| Message ID | 50130F36.4090902@gmail.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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.
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
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
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
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.
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