Lines Matching +full:dma +full:- +full:safe +full:- +full:map
10 Bus-Independent Device Accesses
27 ----------------------------
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
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;
107 outstanding DMA writes from that bus, since for some devices the result of
108 a readb() call may signal to the driver that a DMA transaction is
110 next readb() call has no relation to any previous DMA writes
117 calls, since only a few will indicate or depend on DMA completion.
123 --------------------
134 --------------------
137 allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and
172 MMIO accesses and DMA accesses as well as fixed endianness for accessing
173 little-endian PCI devices and on-chip peripherals. Portable device drivers
177 Documentation/driver-api/io_ordering.rst.
183 DMA, these "relaxed" versions of the MMIO accessors only serialize against
186 comment that explains why the usage in a specific location is safe without
189 See memory-barriers.txt for a more detailed discussion on the precise ordering
190 guarantees of the non-relaxed and relaxed versions.
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
239 is only safe to use these to access memory behind a device bus but not MMIO
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
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
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
352 ioremap_wc() on a device that is known to be safe.
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
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 --------------------
436 Here is how the above modes map to memory attribute settings on the ARM64
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).
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