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

[Rob Herring]

On 08/27/2012 03:27 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 30, 2012 at 09:56:56AM -0500, Rob Herring wrote:
>> On 07/30/2012 09:31 AM, Russell King - ARM Linux wrote:
>>> On Mon, Jul 30, 2012 at 06:05:04AM -0500, Rob Herring wrote:
>>>> On 07/28/2012 09:38 AM, Will Deacon wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On Fri, Jul 27, 2012 at 10:59:18PM +0100, Rob Herring wrote:
>>>>>> Please pull updated io.h cleanup for PCI branch. I rebased this as the
>>>>>> changes shifted things around a bit. This has the following changes:
>>>>>>
>>>>>> - Incorporated fixes from you and Stephen
>>>>>> - Add early i/o mapping pci_map_io_early and enable on footbridge and
>>>>>> integrator for VGA console
>>>>>
>>>>> Unfortunately, I still experience the same hang on integrator with this
>>>>> revised patch series. Given the turnaround time for testing this, I don't
>>>>> think this should block the series, but I would like to get to the bottom of
>>>>> it if possible.
>>>>>
>>>>> I tried annotating the PCI code (including fault handlers) and the VGA
>>>>> console code but I couldn't find the culprit. I suppose the next step is
>>>>> JTAG, but that requires steal^Wborrowing some hardware from work.
>>>>
>>>> I did do some tests with qemu by adding i/o setup to integrator/cp.
>>>> Without it, I would abort on 0xfee003xx (vga regs). Once I added the
>>>> setup, I got to an abort on a PCI memory address which I did not setup.
>>>>
>>>> We can always revert integrator change if we can figure this out...
>>>
>>> Err, Integrator/CP doesn't have PCI nor does it have VGA.  Only the
>>> Integrator/AP has that.
>>
>> Yes, I know. But there is no AP model within qemu. I added the mapping
>> to AP and enabled VGA console to do some basic checks that i/o accesses
>> happen. It didn't really have to be integrator platform at all for this
>> test. I know it's not much of a test, but it's something beyond
>> compiling and staring at the code.
>>
>> I've also tested PCI i/o with versatile under qemu.
> 
> What's the conflict resolution for the fix for ioremap of phys 0 (posted
> by me previously) and your reoganisation and creation of
> vm_reserve_area_early() ?
> 
> Note that I'm taking the autobuilder offline until this is resolved because
> the tree currently isn't in a buildable state because of this.

I believe you can just replace VM_ARM_STATIC_MAPPING with
VM_ARM_EMPTY_MAPPING in vm_reserve_area_early. The pci i/o space and
empty sections are the same until pci_ioremap_io is called, and it does
not care what the vm flags are.

Rob