---
- branch: MAIN
  date: Mon Dec  2 08:33:42 UTC 2019
  files:
  - new: '1.38'
    old: '1.37'
    path: src/sys/dev/pci/pci_map.c
    pathrev: src/sys/dev/pci/pci_map.c@1.38
    type: modified
  id: 20191202T083342Z.f0fb5ed62f25e7d1804a03a483b7f6385ab8685d
  log: |
    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
  module: src
  subject: 'CVS commit: src/sys/dev/pci'
  unixtime: '1575275622'
  user: riastradh