Now
MAIN commitmail json YAML
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
- 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