Lines Matching +full:port +full:- +full:mapping +full:- +full:mode
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;
119 Port Space Accesses
122 Port Space Explained
123 --------------------
125 Another form of IO commonly supported is Port Space. This is a range of
130 Unlike memory mapped IO, no preparation is required to access port
133 Accessing Port Space
134 --------------------
137 allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and
147 port.
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
198 that require special instructions for I/O port access, this adds a small
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()
254 still be in progress. On architectures that correctly implement this, I/O port
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
259 In some architectures, the I/O port number space has a 1:1 mapping to
261 not rely on that for portability. Similarly, an I/O port number as described
262 in a PCI base address register may not correspond to the port number as seen
263 by a device driver. Portable drivers need to read the port number for the
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
287 Device memory mapping modes
290 Some architectures support multiple modes for mapping device memory.
292 architecture-specific modes, with a shared set of semantics.
294 ioremap() is the most common mapping type, and is applicable to typical device
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 ------------
343 This mode is typically used for video framebuffers, where it can increase
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(),
363 This mode is sometimes used for video framebuffers, where drivers still expect
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.
383 This mapping mode primarily exists to cater for platforms with bus fabrics that
384 require this particular mapping mode to work correctly. These platforms set the
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
428 ``__iomem`` token. memremap() can be used for mapping normal RAM that is outside
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
460 automatically choose an appropriate ioremap mode on any given bus, allowing for
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.
504 stricter rules for mapping I/O memory.
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