tree 9717d8e049dd2212ec827dab744517af0706360d
parent 75efba81513133fdd2f9c1ac9213bf86cc622f62
author Krzysztof Hałasa <khalasa@piap.pl> 1393918630 +0100
committer Arnd Bergmann <arnd@arndb.de> 1395066921 +0100

CNS3xxx: Fix PCIe early iotable_init().

This patch fixes the following BUG:

> kernel BUG at mm/vmalloc.c:1132!
> PC is at vm_area_add_early+0x20/0x84
> LR is at add_static_vm_early+0xc/0x60
>
> The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
> iotable_init().

Instead of merely calling the PCIe iotable_init() from
machine_desc->map_io(), this patch adds the required mappings to the
main CNS3xxx mapping table. This means we don't convert .pfn back to
virtual addresses in pcie.c. The size of the address space consumed for
PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this
doesn't include MMIO address space required by PCI devices):

- Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB.
  It's a PCI configuration address space for the local (on-chip) PCIe
  bridge.

- Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for
  Type 0 Configuration accesses, i.e., accesses to the single device
  (with possible "functions") on the other end of the PCIe link.
  We really only need a 4 KiB page at 0x8000 (see the offset
  calculation in cns3xxx_pci_cfg_base()). There is still a potential
  problem with PCI bus numbers > 0xF, are they supported?

- The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should
  be clearer now.

- The maximum address space allocated for PCI MMIO is now correctly
  shown in /proc/iomem as 176 MiB (per each of the two PCI "domains"
  - previously only 16 MiB were reserved).

This patch has been tested on Gateworks Laguna board, masqueraded as
CNS3420VB.

Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>