soc/amd/picasso/acpi: Fix PCI0 MMIO window

The PCI0 MMIO window was defined between TOM and 4 GiB. This was
overlapping with the FCH MMIO devices. The first MMIO device after TOM
is the FCH IOAPIC.

This wasn't causing a problem for linux other than the fact that
/proc/iomem showed all the MMIO devices under the PCI root bridge.
On Windows this was causing all the MMIO devices to have conflicting
resource errors.

BUG=b:175146875
BRANCH=zork
TEST=Boot linux and verify peripherals all work. Boot windows and
verify the i2c controllers show up. The GPIO controller still has a
problem related to power.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Idc409f1318e6da5a693ccbb3da74aafd13f1e058
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49853
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>

src/soc/amd/picasso/acpi/sb_pci0_fch.asl

@@ -1,5 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include <arch/ioapic.h>
+
 External(\_SB.ALIB, MethodObj)
 
 /* System Bus */
@@ -71,16 +73,9 @@ Method(_CRS, 0) {
 	CreateDWordField(CRES, ^MMIO._BAS, MM1B)
 	CreateDWordField(CRES, ^MMIO._LEN, MM1L)
 
-	/*
+	/* Declare memory between TOM1 and IOAPIC as available for PCI MMIO. */
-	 * Declare memory between TOM1 and 4GB as available
-	 * for PCI MMIO.
-	 * Use ShiftLeft to avoid 64bit constant (for XP).
-	 * This will work even if the OS does 32bit arithmetic, as
-	 * 32bit (0x00000000 - TOM1) will wrap and give the same
-	 * result as 64bit (0x100000000 - TOM1).
-	 */
 	MM1B = TOM1
-	Local0 = 0x10000000 << 4
+	Local0 = IO_APIC_ADDR /* This is the first MMIO device after TOM1. */
 	Local0 -= TOM1
 	MM1L = Local0