The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters <Ted.Peters@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Refactor the check to determine if the quirk is applicable to the boards
into one inline function so we only have to change one place to add more
boards that the quirks might be applicable to.
Also removed a warning related to unused temp variable.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The ULI 1575 PCI quirk function for the Freescale MPC8610 HPCD was disabling
the SATA INTx interrupt, even when SATA support was enabled. This was safe,
because the SATA driver re-enabled it. But with commit a5bfc471 ("ahci: drop
intx manipulation on msi enable"), the driver no longer does this, and so SATA
support on the 8610 HPCD is broken.
The original quirk function disabled INTx because it caused some other
interrupt problem during early development on this board, but no one remembers
any more what that problem was, and it doesn't seem to occur any more.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The general pci resume code can only restore part of the
configuration registers. We need to reconfigure those
registers in the FIXUP_RESUME.
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Commit 00c5372d37 caused the MPC8544DS
board to hang at boot. The MPC8544DS is unique in that it doesn't use
the PCI slots on the ULI (unlike the MPC8572DS or MPC8610HPCD). So
the dummy read at the end of the address space causes us to hang.
We can detect the situation by comparing the bridge's BARs versus
the root complex.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
- Get rid of uses_fsl_uli_m1575, it does not scale for all cases.
Instead, let's explicitly use machine_is() for each fixup.
- Factor out MPC8610HPCD quirks to fsl_uli1575, and protect them with
machine_is(). One step closer to multiplatform kernels.
- Actually use fsl_uli1575 on MPC8610HPCD, so RTC quirk will be applied.
- RTC quirk applies to all boards though, so no machine_is() checks.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch fixes RTC on MPC8572DS boards: dummy read helps only when
reading at the end of the bridge's memory (i.e. outside of behind the
bridge devices' assigned regions).
With this change the quirk also makes RTC work on MPC8610HPCD, so it's
unlikely that this will break MPC8641HPCN or MPC8544DS boards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The interrupt routing in the device trees for the ULI M1575 was
inproperly using the interrupt line field as pci function. Fixed
up the device tree's to actual conform for to specification and
changed the interrupt mapping code so it just uses a static mapping
setup as follows:
PIRQA - IRQ9
PIRQB - IRQ10
PIRQC - IRQ11
PIRQD - IRQ12
USB 1.1 OCHI (1c.0) - IRQ12
USB 1.1 OCHI (1c.1) - IRQ9
USB 1.1 OCHI (1c.2) - IRQ10
USB 1.1 ECHI (1c.3) - IRQ11
LAN (1b.0) - IRQ6
AC97 (1d.0) - IRQ6
Modem (1d.1) - IRQ6
HD Audio (1d.2) - IRQ6
SATA (1f.1) - IRQ5
SMB (1e.1) - IRQ7
PMU (1e.2) - IRQ7
PATA (1f.0) - IRQ14/15
Took the oppurtunity to refactor the code into a single file so we
don't have to duplicate these fixes on the two current boards in the
tree and several forth coming boards that will also need the code.
Fixed RTC support that requires a dummy memory read on the P2P bridge
to unlock the RTC and setup the default of the RTC alarm registers to
match with a basic x86 style CMOS RTC.
Moved code that poked ISA registers to a FIXUP_FINAL quirk to ensure
the PCI IO space has been setup properly before we start poking ISA
registers at random locations.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
