aboutsummaryrefslogtreecommitdiff
path: root/target-i386
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2016-10-18 17:02:49 +1100
committerDavid Gibson <david@gibson.dropbear.id.au>2016-10-28 09:38:27 +1100
commita795fc08f2636013fe097e51bdac62d089ac505a (patch)
tree42d6e2e8ed55611a33149a1529968690b024e6a7 /target-i386
parent246fc0fb66cbf861b0e76320626b059e2d49ea12 (diff)
libqos: Handle PCI IO de-multiplexing in common code
The PCI IO space (aka PIO, aka legacy IO) and PCI memory space (aka MMIO) are distinct address spaces by the PCI spec (although parts of one might be aliased to parts of the other in some cases). However, qpci_io_read*() and qpci_io_write*() can perform accesses to either space depending on parameter. That's convenient for test case drivers, since there are a fair few devices which can be controlled via either a PIO or MMIO BAR but with an otherwise identical driver. This is implemented by having addresses below 64kiB treated as PIO, and those above treated as MMIO. This works because low addresses in memory space are generally reserved for DMA rather than MMIO. At the moment, this demultiplexing must be handled by each PCI backend (pc and spapr, so far). There's no real reason for this - the current encoding is likely to work for all platforms, and even if it doesn't we can still use a more complex common encoding since the value returned from iomap are semi-opaque. This patch moves the demultiplexing into the common part of the libqos PCI code, with the backends having simpler, separate accessors for PIO and MMIO space. This also means we have a way of explicitly accessing either space if it's necessary for some special case. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Diffstat (limited to 'target-i386')
0 files changed, 0 insertions, 0 deletions