| blob | f3aab76e357a07f6d78d34c2b62119af4b7e0d4e |
1 // SPDX-License-Identifier: GPL-2.0-or-later
2 /*
3 * Low-level PCI config space access for OLPC systems who lack the VSA
4 * PCI virtualization software.
5 *
6 * Copyright © 2006 Advanced Micro Devices, Inc.
7 *
8 * The AMD Geode chipset (ie: GX2 processor, cs5536 I/O companion device)
9 * has some I/O functions (display, southbridge, sound, USB HCIs, etc)
10 * that more or less behave like PCI devices, but the hardware doesn't
11 * directly implement the PCI configuration space headers. AMD provides
12 * "VSA" (Virtual System Architecture) software that emulates PCI config
13 * space for these devices, by trapping I/O accesses to PCI config register
14 * (CF8/CFC) and running some code in System Management Mode interrupt state.
15 * On the OLPC platform, we don't want to use that VSA code because
16 * (a) it slows down suspend/resume, and (b) recompiling it requires special
17 * compilers that are hard to get. So instead of letting the complex VSA
18 * code simulate the PCI config registers for the on-chip devices, we
19 * just simulate them the easy way, by inserting the code into the
20 * pci_write_config and pci_read_config path. Most of the config registers
21 * are read-only anyway, so the bulk of the simulation is just table lookup.
22 */
24 #include <linux/pci.h>
25 #include <linux/init.h>
26 #include <asm/olpc.h>
27 #include <asm/geode.h>
28 #include <asm/pci_x86.h>
30 /*
31 * In the tables below, the first two line (8 longwords) are the
32 * size masks that are used when the higher level PCI code determines
33 * the size of the region by writing ~0 to a base address register
34 * and reading back the result.
35 *
36 * The following lines are the values that are read during normal
37 * PCI config access cycles, i.e. not after just having written
38 * ~0 to a base address register.
39 */
52 };
65 };
78 };
91 };
104 };
118 };
131 };
142 44 is mask 8103 (power control) */
145 };
156 mask 8103 (power control) */
157 #if 0
159 #endif
162 61 FLADJ (R/W), PORTWAKECAP */
163 };
174 {
177 }
180 {
183 /*
184 * This is a little bit tricky. The header maps consist of
185 * 0x20 bytes of size masks, followed by 0x70 bytes of header data.
186 * In the normal case, when not probing a BAR's size, we want
187 * to access the header data, so we add 0x20 to the reg offset,
188 * thus skipping the size mask area.
189 * In the BAR probing case, we want to access the size mask for
190 * the BAR, so we subtract 0x10 (the config header offset for
191 * BAR0), and don't skip the size mask area.
192 */
198 }
202 {
207 /* Use the hardware mechanism for non-simulated devices */
211 /*
212 * No device has config registers past 0x70, so we save table space
213 * by not storing entries for the nonexistent registers
214 */
243 }
244 }
257 }
260 }
264 {
267 /* Use the hardware mechanism for non-simulated devices */
271 /* XXX we may want to extend this to simulate EHCI power management */
273 /*
274 * Mostly we just discard writes, but if the write is a size probe
275 * (i.e. writing ~0 to a BAR), we remember it and arrange to return
276 * the appropriate size mask on the next read. This is cheating
277 * to some extent, because it depends on the fact that the next
278 * access after such a write will always be a read to the same BAR.
279 */
282 /* write is to a BAR */
286 /*
287 * No warning on writes to ROM BAR, CMD, LATENCY_TIMER,
288 * CACHE_LINE_SIZE, or PM registers.
289 */
295 }
298 }
303 };
306 {
311 }