summaryrefslogtreecommitdiff
path: root/sys/dev
diff options
context:
space:
mode:
authorriastradh <riastradh@NetBSD.org>2019-12-02 08:33:42 +0000
committerriastradh <riastradh@NetBSD.org>2019-12-02 08:33:42 +0000
commit4c6cbbdc0e6001a4ff1df346922e263ad8a30cf7 (patch)
tree38da356879f4a25b7593275dd5fbdc28595bdf06 /sys/dev
parentec9e7766cab543c54ab276510d61680bca1d8280 (diff)
Use BUS_SPACE_MAP_PREFETCHABLE only if BAR and driver agree on it.
- A driver that expects prefetchable memory and knows to issue the needed bus_space_barrier calls can pass BUS_SPACE_MAP_PREFETCHABLE to indicate a desire to map the memory prefetchable if the BAR allows it. (A driver that _really wants_ BUS_SPACE_MAP_PREFETCHABLE even if the BAR claims _not_ to be prefetchable can use pci_mapreg_info and bus_space_map explicitly -- this is not different from what we have today.) - For a driver that _does not_ expect prefetchable memory, the appearance of the prefetchable bit in the BAR shouldn't cause it to use BUS_SPACE_MAP_PREFETCHABLE, because the driver will not issue the needed bus_space_barrier calls to get sensible results. Note: `Prefetchable' here, sometimes called `write-combining', means reads have no side effects, and writes are idempotent, so it is safe to issue reads out of order and safe to combine writes. Mappings with BUS_SPACE_MAP_PREFETCHABLE are often more weakly ordered than normal memory -- e.g., on x86, in WC-type memory regions, loads can be reordered with loads, stores can be reordered with stores, which is not possible with any other type of memory regions. Discussed on tech-kern a while ago: https://mail-index.NetBSD.org/tech-kern/2017/03/22/msg021678.html This is option A, which received the most support. This should help unconfuse drivers that do not expect prefetchable mappings, like Yamaguchi-san tripped over recently: https://mail-index.NetBSD.org/tech-kern/2019/12/02/msg025785.html
Diffstat (limited to 'sys/dev')
-rw-r--r--sys/dev/pci/pci_map.c24
1 files changed, 21 insertions, 3 deletions
diff --git a/sys/dev/pci/pci_map.c b/sys/dev/pci/pci_map.c
index c54d0041bf0..2f724163add 100644
--- a/sys/dev/pci/pci_map.c
+++ b/sys/dev/pci/pci_map.c
@@ -1,4 +1,4 @@
-/* $NetBSD: pci_map.c,v 1.37 2019/03/01 05:41:56 msaitoh Exp $ */
+/* $NetBSD: pci_map.c,v 1.38 2019/12/02 08:33:42 riastradh Exp $ */
/*-
* Copyright (c) 1998, 2000 The NetBSD Foundation, Inc.
@@ -34,7 +34,7 @@
*/
#include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: pci_map.c,v 1.37 2019/03/01 05:41:56 msaitoh Exp $");
+__KERNEL_RCSID(0, "$NetBSD: pci_map.c,v 1.38 2019/12/02 08:33:42 riastradh Exp $");
#include <sys/param.h>
#include <sys/systm.h>
@@ -328,7 +328,25 @@ pci_mapreg_submap(const struct pci_attach_args *pa, int reg, pcireg_t type,
if (realmaxsize < (offset + reqsize))
return 1;
- if (bus_space_map(tag, base, reqsize, busflags | flags, &handle))
+ /*
+ * If the BAR doesn't say prefetchable, assume the mapping
+ * cannot be prefetchable. In other words, we will use
+ * BUS_SPACE_MAP_PREFETCHABLE only if the driver requested it
+ * _and_ the BAR indicates it is prefetchable.
+ *
+ * Drivers that expect prefetchable memory will issue the
+ * appropriate barriers, whereas drivers that do not expect
+ * prefetchable memory will be terribly confused if the memory
+ * is mapped prefetchable.
+ *
+ * Drivers that want to override the BAR and map it with
+ * BUS_SPACE_MAP_PREFETCHABLE anyway can use pci_mapreg_map and
+ * bus_space_map explicitly.
+ */
+ if (!ISSET(flags, BUS_SPACE_MAP_PREFETCHABLE))
+ busflags &= ~BUS_SPACE_MAP_PREFETCHABLE;
+
+ if (bus_space_map(tag, base, reqsize, busflags, &handle))
return 1;
if (pci_mapreg_map_enable_decode) {