iommupt: Documentation fixes

Some adjustments pointed out by Randy:

 "decodes an full 64-bit" -> "decodes the full 64 bit"

 Correct the function parameter name for iova_to_phys()

 Use the recommended section heading style.

Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: ab0b572847 ("genpt: Add Documentation/ files")
Fixes: 879ced2bab ("iommupt: Add the AMD IOMMU v1 page table format")
Fixes: 9d4c274cd7 ("iommupt: Add iova_to_phys op")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This commit is contained in:
Jason Gunthorpe 2025-11-06 15:02:14 -04:00 committed by Joerg Roedel
parent e4dfaf25df
commit 5cb637d942
3 changed files with 5 additions and 10 deletions

View File

@ -10,9 +10,8 @@ Generic Radix Page Table
.. kernel-doc:: drivers/iommu/generic_pt/pt_defs.h
:doc: Generic Page Table Language
-----
Usage
-----
=====
Generic PT is structured as a multi-compilation system. Since each format
provides an API using a common set of names there can be only one format active
@ -61,7 +60,6 @@ format-specific information.
The implementation will further wrap struct pt_common in its own top-level
struct, such as struct pt_iommu_amdv1.
----------------------------------------------
Format functions at the struct pt_common level
----------------------------------------------
@ -69,13 +67,11 @@ Format functions at the struct pt_common level
:identifiers:
.. kernel-doc:: drivers/iommu/generic_pt/pt_common.h
-----------------
Iteration Helpers
-----------------
.. kernel-doc:: drivers/iommu/generic_pt/pt_iter.h
----------------
Writing a Format
----------------
@ -112,7 +108,6 @@ The generic tests are intended to prove out the format functions and give
clearer failures to speed up finding the problems. Once those pass then the
entire kunit suite should be run.
---------------------------
IOMMU Invalidation Features
---------------------------
@ -124,7 +119,7 @@ on its design. Every HW has its own approach on how to describe what has changed
to have changed items removed from the TLB.
PT_FEAT_FLUSH_RANGE
-------------------
~~~~~~~~~~~~~~~~~~~
PT_FEAT_FLUSH_RANGE is the easiest scheme to understand. It tries to generate a
single range invalidation for each operation, over-invalidating if there are
@ -134,7 +129,7 @@ however, if pages have to be freed then page table pointers have to be cleaned
from the walk cache. The range can start/end at any page boundary.
PT_FEAT_FLUSH_RANGE_NO_GAPS
---------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~
PT_FEAT_FLUSH_RANGE_NO_GAPS is similar to PT_FEAT_FLUSH_RANGE; however, it tries
to minimize the amount of impacted VA by issuing extra flush operations. This is

View File

@ -38,7 +38,7 @@ config IOMMU_PT_AMDV1
help
iommu_domain implementation for the AMD v1 page table. AMDv1 is the
"host" page table. It supports granular page sizes of almost every
power of 2 and decodes an full 64-bit IOVA space.
power of 2 and decodes the full 64-bit IOVA space.
Selected automatically by an IOMMU driver that uses this format.

View File

@ -158,7 +158,7 @@ PT_MAKE_LEVELS(__iova_to_phys, __do_iova_to_phys);
/**
* iova_to_phys() - Return the output address for the given IOVA
* @iommu_table: Table to query
* @domain: Table to query
* @iova: IO virtual address to query
*
* Determine the output address from the given IOVA. @iova may have any