Skip to content

Commit 9bf6f7b

Browse files
committed
Documentation/io-mapping: Remove outdated blurb
The implementation details in the documentation are outdated and not really helpful. Remove them. Signed-off-by: Thomas Gleixner <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Andrew Morton <[email protected]> Link: https://lore.kernel.org/r/[email protected]
1 parent 351191a commit 9bf6f7b

File tree

1 file changed

+0
-22
lines changed

1 file changed

+0
-22
lines changed

Documentation/driver-api/io-mapping.rst

Lines changed: 0 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -73,25 +73,3 @@ for pages mapped with io_mapping_map_wc.
7373
At driver close time, the io_mapping object must be freed::
7474

7575
void io_mapping_free(struct io_mapping *mapping)
76-
77-
Current Implementation
78-
======================
79-
80-
The initial implementation of these functions uses existing mapping
81-
mechanisms and so provides only an abstraction layer and no new
82-
functionality.
83-
84-
On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole
85-
range, creating a permanent kernel-visible mapping to the resource. The
86-
map_atomic and map functions add the requested offset to the base of the
87-
virtual address returned by ioremap_wc.
88-
89-
On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses
90-
kmap_atomic_pfn to map the specified page in an atomic fashion;
91-
kmap_atomic_pfn isn't really supposed to be used with device pages, but it
92-
provides an efficient mapping for this usage.
93-
94-
On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and
95-
io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which
96-
performs an IPI to inform all processors about the new mapping. This results
97-
in a significant performance penalty.

0 commit comments

Comments
 (0)