Lines Matching +full:non +full:- +full:pci
10 Bus-Independent Device Accesses
27 ----------------------------
33 devices. The PCI bus walk is a good example of such a scheme. This
49 --------------------
52 memory-mapped registers on the device. Linux provides interfaces to read
53 and write 8-bit, 16-bit, 32-bit and 64-bit quantities. Due to a
76 are burned by the fact that PCI bus writes are posted asynchronously. A
82 from config space, which is guaranteed to soft-fail if the card doesn't
94 reg = ha->iobase;
96 WRT_REG_WORD(®->ictrl, 0);
102 RD_REG_WORD(®->ictrl);
103 ha->flags.ints_enabled = 0;
106 PCI ordering rules also guarantee that PIO read responses arrive after any
123 --------------------
134 --------------------
137 allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and
173 little-endian PCI devices and on-chip peripherals. Portable device drivers
177 Documentation/driver-api/io_ordering.rst.
189 See memory-barriers.txt for a more detailed discussion on the precise ordering
190 guarantees of the non-relaxed and relaxed versions.
197 for mapping PCI I/O space with pci_iomap() or ioport_map(). On architectures
206 reversed byte order, for accessing devices with big-endian MMIO registers.
207 Device drivers that can operate on either big-endian or little-endian
213 using a hardware byte-reverse on the PCI bus when running a big-endian kernel.
222 Some device drivers have 64-bit registers that cannot be accessed atomically
223 on 32-bit architectures but allow two consecutive 32-bit accesses instead.
225 accessed first, a helper is provided for each combination of 64-bit accessors
227 either <linux/io-64-nonatomic-lo-hi.h> or <linux/io-64-nonatomic-hi-lo.h> to
229 readq()/writeq() to them on architectures that do not provide 64-bit access
235 These are low-level MMIO accessors without barriers or byteorder changes and
237 a four-byte __raw_readl() does not get split into individual byte loads, but
247 PCI I/O port resources traditionally require separate helpers as they are
251 ``__iomem`` pointer, the address is a 32-bit integer token to identify a port
252 number. PCI requires I/O port access to be non-posted, meaning that an outb()
255 access is therefore ordered against spinlocks. Many non-x86 PCI host bridge
256 implementations and CPU architectures however fail to implement non-posted I/O
257 space on PCI, so they can end up being posted on such hardware.
262 in a PCI base address register may not correspond to the port number as seen
266 There are no direct 64-bit I/O port accessors, but pci_iomap() in combination
283 MMIO accessors, these do not perform a byteswap on big-endian kernels, so the
292 architecture-specific modes, with a shared set of semantics.
300 ---------
302 The default mode, suitable for most memory-mapped devices, e.g. control
305 * Uncached - CPU-side caches are bypassed, and all reads and writes are handled
307 * No speculative operations - the CPU may not issue a read or write to this
310 * No reordering - The CPU may not reorder accesses to this memory mapping with
313 * No repetition - The CPU may not issue multiple reads or writes for a single
315 * No write-combining - Each I/O operation results in one discrete read or write
319 * Non-executable - The CPU is not allowed to speculate instruction execution
323 On many platforms and buses (e.g. PCI), writes issued through ioremap()
331 ------------
349 On a PCI bus, it is usually safe to use ioremap_wc() on MMIO areas marked as
351 For on-chip devices, there is no corresponding flag, but a driver can use
355 ------------
357 Maps I/O memory as normal memory with write-through caching. Like ioremap_wc(),
371 ------------
373 Like ioremap(), but explicitly requests non-posted write semantics. On some
379 devices. ioremap_np() explicitly requests non-posted semantics, which means
381 received (and to some platform-specific extent acknowledged) the written data.
387 selects it where appropriate (see the `Higher-level ioremap abstractions`_
392 platform-specific or they derive benefit from non-posted writes where
398 ioremap_np() should never be used for PCI drivers. PCI memory space writes are
400 Using ioremap_np() for PCI BARs will at best result in posted write semantics,
403 Note that non-posted write semantics are orthogonal to CPU-side ordering
405 non-posted write instruction retires. See the previous section on MMIO access
409 ------------
411 ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension,
419 ---------------
421 ioremap_cache() effectively maps I/O memory as normal RAM. CPU write-back
434 --------------------
439 +------------------------+--------------------------------------------+
441 +------------------------+--------------------------------------------+
442 | ioremap_np() | Device-nGnRnE |
443 +------------------------+--------------------------------------------+
444 | ioremap() | Device-nGnRE |
445 +------------------------+--------------------------------------------+
447 +------------------------+--------------------------------------------+
448 | ioremap_wc() | Normal-Non Cacheable |
449 +------------------------+--------------------------------------------+
451 +------------------------+--------------------------------------------+
452 | ioremap_cache() | Normal-Write-Back Cacheable |
453 +------------------------+--------------------------------------------+
455 Higher-level ioremap abstractions
459 higher-level APIs. These APIs may implement platform-specific logic to
461 a platform-agnostic driver to work on those platforms without any special
472 Documented in Documentation/driver-api/driver-model/devres.rst.
477 require non-posted writes for certain buses (see the nonposted-mmio and
478 posted-mmio device tree properties).
488 Maps the resource described in a PCI base address without having to extract
501 Documented in Documentation/driver-api/driver-model/devres.rst.
509 .. kernel-doc:: include/linux/iosys-map.h
512 .. kernel-doc:: include/linux/iosys-map.h
518 .. kernel-doc:: arch/x86/include/asm/io.h