On 4/11/22 16:46, Robin Murphy wrote:
> @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct
> host1x_device *dev)
> struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
> struct iommu_domain *domain;
>
> + /* For starters, this is moot if no IOMMU is available
Once the group enters 'owned' mode it can never be assigned back to the
default_domain or to a NULL domain. It must always be actively assigned to
a current domain. If the caller hasn't provided a domain then the core
must provide an explicit DMA blocking domain that has no DMA map.
Lazily create
A basic device-specific linear memory mapping was introduced back in
commit ("dma: Take into account dma_pfn_offset") as a single-valued offset
preserved in the device.dma_pfn_offset field, which was initialized for
instance by means of the "dma-ranges" DT property. Afterwards the
functionality
On Mon, May 02, 2022 at 09:48:42AM +0800, Lu Baolu wrote:
> Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
> for SVA implementation in iommu core.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
> ---
> drivers/iommu/{iommu-sva-lib.h => iommu-sva.h} | 0
>
On Mon, May 02, 2022 at 09:48:41AM +0800, Lu Baolu wrote:
> Tweak the I/O page fault handling framework to route the page faults to
> the domain and call the page fault handler retrieved from the domain.
> This makes the I/O page fault handling framework possible to serve more
> usage scenarios as
On Mon, May 02, 2022 at 09:48:40AM +0800, Lu Baolu wrote:
> This adds some mechanisms around the iommu_domain so that the I/O page
> fault handling framework could route a page fault to the domain and
> call the fault handler from it.
>
> Add pointers to the page fault handler and its private
On Mon, May 02, 2022 at 09:48:39AM +0800, Lu Baolu wrote:
> These ops'es have been replaced with the dev_attach/detach_pasid domain
> ops'es. There's no need for them anymore. Remove them to avoid dead
> code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
> ---
>
On Mon, May 02, 2022 at 09:48:37AM +0800, Lu Baolu wrote:
> Add support for SVA domain allocation and provide an SVA-specific
> iommu_domain_ops.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 +++
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 42
On Mon, May 02, 2022 at 09:48:34AM +0800, Lu Baolu wrote:
> Use below data structures for SVA implementation in the IOMMU core:
>
> - struct iommu_sva_ioas
> Represent the I/O address space shared with an application CPU address
> space. This structure has a 1:1 relationship with an
On Mon, May 02, 2022 at 09:48:33AM +0800, Lu Baolu wrote:
> Attaching an IOMMU domain to a PASID of a device is a generic operation
> for modern IOMMU drivers which support PASID-granular DMA address
> translation. Currently visible usage scenarios include (but not limited):
>
> - SVA (Shared
On Mon, May 02, 2022 at 09:48:32AM +0800, Lu Baolu wrote:
> Use this field to save the pasid/ssid bits that a device is able to
> support with its IOMMU hardware. It is a generic attribute of a device
> and lifting it into the per-device dev_iommu struct makes it possible
> to allocate a PASID for
On 2022-05-03 16:23, Jason Gunthorpe wrote:
On Tue, May 03, 2022 at 02:04:37PM +0100, Robin Murphy wrote:
I'm guessing SMMU3 needs to call it's arm_smmu_detach_dev(master) from
the detach_dev op and null it's cached copy of the domain, but I don't
know this driver.. Robin?
The original
Hi YF,
> The calling to kmem_cache_alloc for level 2 page table allocation may
> run in atomic context, and it fails sometimes when DMA32 zone runs out
> of memory.
>
> Since Mediatek IOMMU hardware support at most 35bit PA in page table,
s/Mediatek/MediaTek/
s/support/supports/
> so add a
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMU during probe().
Signed-off-by: Jon Nettleton
Signed-off-by:
Check if there is any RMR info associated with the devices behind
the SMMUv3 and if any, install bypass STEs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMUv3 during probe().
Signed-off-by: Shameer Kolothum
---
By default, disable_bypass flag is set and any dev without
an iommu domain installs STE with CFG_ABORT during
arm_smmu_init_bypass_stes(). Introduce a "force" flag and
move the STE update logic to arm_smmu_init_bypass_stes()
so that we can force it to install CFG_BYPASS STE for specific
SIDs.
Introduce a helper to check the sid range and to init the l2 strtab
entries(bypass). This will be useful when we have to initialize the
l2 strtab with bypass for RMR SIDs.
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 28 +++--
1 file changed,
This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
---
drivers/acpi/arm64/iort.c | 28
include/linux/acpi_iort.h |
Parse through the IORT RMR nodes and populate the reserve region list
corresponding to a given IOMMU and device(optional). Also, go through
the ID mappings of the RMR node and retrieve all the SIDs associated
with it.
Reviewed-by: Lorenzo Pieralisi
Tested-by: Steven Price
Signed-off-by: Shameer
Currently IORT provides a helper to retrieve HW MSI reserve regions.
Change this to a generic helper to retrieve any IORT related reserve
regions. This will be useful when we add support for RMR nodes in
subsequent patches.
[Lorenzo: For ACPI IORT]
Reviewed-by: Lorenzo Pieralisi
Reviewed-by:
At present iort_iommu_msi_get_resv_regions() returns the number of
MSI reserved regions on success and there are no users for this.
The reserved region list will get populated anyway for platforms
that require the HW MSI region reservation. Hence, change the
function to return void instead.
A callback is introduced to struct iommu_resv_region to free memory
allocations associated with the reserved region. This will be useful
when we introduce support for IORT RMR based reserved regions.
Reviewed-by: Christoph Hellwig
Tested-by: Steven Price
Signed-off-by: Shameer Kolothum
---
Hi
v11 --> v12
-Minor fix in patch #4 to address the issue reported by the kernel test robot.
-Added R-by tags by Christoph(patch #1) and Lorenzo(patch #4).
-Added T-by from Steve to all relevant patches. Many thanks!.
Please note, this series has a dependency on the ACPICA header patch
Add the Qualcomm SC8280XP platform to the list of compatible for which
the Qualcomm-impl of the ARM SMMU should apply.
Signed-off-by: Bjorn Andersson
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
This adds the compatible for the Qualcomm SC8280XP platform and associate the
Qualcomm impl in the ARM SMMU driver to it.
Bjorn Andersson (2):
dt-bindings: arm-smmu: Add compatible for Qualcomm SC8280XP
iommu/arm-smmu-qcom: Add SC8280XP support
Add compatible for the Qualcomm SC8280XP platform to the ARM SMMU
DeviceTree binding.
Signed-off-by: Bjorn Andersson
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
On 03/05/2022 09:13, Yong Wu wrote:
This patchset adds MT8195 and MT8186 iommu support.
MT8195 have 3 IOMMU HWs. 2 IOMMU HW is for multimedia, and 1 IOMMU HW is
for infra-master, like PCIe/USB.
About the 2 MM IOMMU HW, something like this:
IOMMU(VDO) IOMMU(VPP)
On Tue, May 03, 2022 at 02:04:37PM +0100, Robin Murphy wrote:
> > I'm guessing SMMU3 needs to call it's arm_smmu_detach_dev(master) from
> > the detach_dev op and null it's cached copy of the domain, but I don't
> > know this driver.. Robin?
>
> The original intent was that .detach_dev is
On 2022-05-02 17:42, Jason Gunthorpe wrote:
On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
Hi Joerg,
This is a resend version of v8 posted here:
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
___
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> .../devicetree/bindings/dma/renesas,rcar-dmac.yaml | 10
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. I2C on R-Car V3U also supports some extra features (e.g. Slave
> Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
> not by any other R-Car Gen3 SoC.
On 02/05/2022 15:34, Geert Uytterhoeven wrote:
> Despite the name, R-Car V3U is the first member of the R-Car Gen4
> family. Hence move its compatible value to the R-Car Gen4 section.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 02/05/2022 10:37, Rohit Agarwal wrote:
> Add devicetree binding for Qualcomm SDX65 SMMU.
>
> Signed-off-by: Rohit Agarwal
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
On 5/2/22 19:52, Jason Gunthorpe wrote:
> On Mon, May 02, 2022 at 12:11:07PM -0600, Alex Williamson wrote:
>> On Fri, 29 Apr 2022 05:45:20 +
>> "Tian, Kevin" wrote:
From: Joao Martins
3) Unmapping an IOVA range while returning its dirty bit prior to
unmap. This case is
Hi YF,
Thanks very much for this patch. Nearly all the lastest SoC like
mt8192/mt8195 support this.
On Fri, 2022-04-29 at 22:34 +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> Add the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT support, so that
> level 2 page table can allocate in
On Sat, Apr 30, 2022 at 03:33:17PM +0800, Baolu Lu wrote:
> Jean, another quick question about the iommu_sva_bind_device()
>
> /**
> * iommu_sva_bind_device() - Bind a process address space to a device
> * @dev: the device
> * @mm: the mm to bind, caller must hold a reference to it
> *
Add mt8186 iommu supports.
Signed-off-by: Anan Sun
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c
Enable the multi-bank functions for infra-iommu. We put PCIE in bank0
and USB in the last bank(bank4). and we don't use the other banks
currently, disable them.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 7 +--
1 file changed, 5
Each bank has some independent registers. thus backup/restore them for
each a bank when suspend and resume.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 46 ++-
1 file changed, 31 insertions(+), 15
The registers for each bank of the IOMMU base are in order, delta is
0x1000. Initialise the base for each bank.
For all the previous SoC, we only have bank0. thus use "do {} while()"
to allow bank0 always go.
When removing the device, Not always all the banks are initialised, it
depend on if
We preassign some ports in a special bank via the new defined
banks_portmsk. Put it in the plat_data means it is not expected to be
adjusted dynamically.
If the iommu id in the iommu consumer's dtsi node is inside this
banks_portmsk, then we switch it to this special iommu bank, and
initialise
Prepare for adding bankid, also no functional change.
In the previous SoC, each a iova_region is a domain; In the multi-banks
case, each a bank is a domain, then the original function name
"mtk_iommu_get_domain_id" is not proper. Use "iova_region_id" instead of
"domain_id".
Signed-off-by: Yong
The mt8195 IOMMU HW max support 5 banks, and regarding the banks'
registers, it looks like:
|bank0 | bank1 | bank2 | bank3 | bank4|
|global |
|control| null
|regs |
Prepare for supporting multi-banks for the IOMMU HW, No functional change.
Add a new structure(mtk_iommu_bank_data) for each a bank. Each a bank have
the independent HW base/IRQ/tlb-range ops, and each a bank has its special
iommu-domain(independent pgtable), thus, also move the domain
No functional change. Just rename this for readable. Differentiate this
from mtk_iommu.c
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu_v1.c | 211 +--
1 file changed, 103 insertions(+), 108 deletions(-)
diff --git
Currently there is a suspend structure in the header file. It's no need
to keep a header file only for this. Move these into the c file and rm
this header file.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c| 14 +-
Prepare for adding the structure "mtk_iommu_bank_data". No functional
change. The mtk_iommu_domain in v1 and v2 are different, we could not add
current data as bank[0] in v1 simplistically.
Currently we have no plan to add new SoC for v1, in order to avoid affect
v1 when we add many new features
No functional change too, prepare for mt8195 IOMMU support bank functions.
Some global control settings are in bank0 while the other banks have
their bank independent setting. Here only move the global control
settings and the independent registers together.
Signed-off-by: Yong Wu
Reviewed-by:
No functional change. Use "base" instead of the data->base. This is
avoid to touch too many lines in the next patches.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 51 +--
1 file changed, 27 insertions(+),
mt8195 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo, the other
is for vpp. and 1 INFRA IOMMU.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 41 +++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 42
The infra iommu enable bits in mt8195 is in the pericfg register segment,
use regmap to update it.
If infra iommu master translation fault, It doesn't have the larbid/portid,
thus print out the whole register value.
Since regmap_update_bits may fail, add return value for mtk_iommu_config.
Currently the code for of_iommu_configure_dev_id is like this:
static int of_iommu_configure_dev_id(struct device_node *master_np,
struct device *dev,
const u32 *id)
{
struct of_phandle_args iommu_spec = {
The power/clock of infra iommu is always on, and it doesn't have the
device link with the master devices, then the infra iommu device's PM
status is not active, thus we add A PM_CLK_AO flag for infra iommu.
The tlb operation is a bit not clear here, there are 2 special cases.
Comment them in the
Allow the type IOMMU_DOMAIN_UNMANAGED since vfio_iommu_type1.c always call
iommu_domain_alloc. The PCIe EP works ok when going through vfio.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
For MM IOMMU, We always add device link between smi-common and IOMMU HW.
In mt8195, we add smi-sub-common. Thus, if the node is sub-common, we still
need find again to get smi-common, then do device link.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
Prepare for supporting INFRA_IOMMU, and APU_IOMMU later.
For Infra IOMMU/APU IOMMU, it doesn't have the "larb""port". thus, Use
the MM flag contain the MM_IOMMU special flow, Also, it moves a big
chunk code about parsing the mediatek,larbs into a function, this is
only needed for MM IOMMU. and
Add IOMMU_TYPE definition. In the mt8195, we have another IOMMU_TYPE:
infra iommu, also there will be another APU_IOMMU, thus, use 2bits for the
IOMMU_TYPE.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 12 ++--
1 file changed, 10
In prevous SoC, the sub common id occupy 2 bits. the mt8195's sub common
id has 3bits. Add a new flag for this. and rename the previous flag to
_2BITS. For readable, I put these two flags together, then move the
other flags. no functional change.
Signed-off-by: Yong Wu
Reviewed-by:
Currently the output PA[32:33] is contained by the flag IOVA_34.
This is not right. the iova_34 has no relation with pa[32:33], the 32bits
iova still could map to pa[32:33]. Move it out from the flag.
No need fix tag since currently only mt8192 use the calulation and it
always has this IOVA_34
The MediaTek IOMMU doesn't care about granule when tlb flushing.
Remove this variable.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c
Add a new flag STD_AXI_MODE which is prepared for infra and apu iommu
which use the standard axi mode. All the current SoC don't use this flag.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
In the infra iommu, we should disable DCM. add a new flag for this.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
In mt8192, we preassign 0-4G; 4G-8G; 8G-12G for different multimedia
engines. This depends on the "dma-ranges=" in the iommu consumer's dtsi
node.
Adds 12G-16G region here. and reword the previous comment. we don't limit
which master locate in which region.
CCU still is 8G-12G. Don't change it
In previous mt2712, Both IOMMUs are MM IOMMU, and they will share pgtable.
However in the latest SoC, another is infra IOMMU, there is no reason to
share pgtable between MM with INFRA IOMMU. This patch manage to
implement the two case(sharing and non-sharing pgtable).
Currently we use
Same with the previous patch, add a mutex for the "data" in the
mtk_iommu_domain. Just improve the safety for multi devices
enter attach_device at the same time. We don't get the real issue
for this.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/iommu/mtk_iommu.c
Add a mutex to protect the data in the structure mtk_iommu_data,
like ->"m4u_group" ->"m4u_dom". For the internal data, we should
protect it in ourselves driver. Add a mutex for this.
This could be a fix for the multi-groups support.
Fixes: c3045f39244e ("iommu/mediatek: Support for multi
Lack the list_del in the mtk_iommu_remove, and remove
bus_set_iommu(*, NULL) since there may be several iommu HWs.
we can not bus_set_iommu null when one iommu driver unbind.
This could be a fix for mt2712 which support 2 M4U HW and list them.
Fixes: 7c3a2ec02806 ("iommu/mediatek: Merge 2 M4U
After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on
resume"), the iommu clock is controlled by the runtime callback.
thus remove the clk control in the mtk_iommu_remove.
Otherwise, it will warning like:
echo 14018000.iommu > /sys/bus/platform/drivers/mtk-iommu/unbind
[
In the commit 4f956c97d26b ("iommu/mediatek: Move domain_finalise into
attach_device"), I overlooked the sharing pgtable case.
After that commit, the "data" in the mtk_iommu_domain_finalise always is
the data of the current IOMMU HW. Fix this for the sharing pgtable case.
Only affect mt2712 which
Add mt8186 iommu binding. "-mm" means the iommu is for Multimedia.
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Reviewed-by: Matthias Brugger
Reviewed-by: AngeloGioacchino Del Regno
---
.../bindings/iommu/mediatek,iommu.yaml| 4 +
In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
mainly are PCIe and USB. Different with MM IOMMU, all these masters
connect with IOMMU directly, there is no mediatek,larbs property for
infra IOMMU.
Another thing is about PCIe ports. currently the function
This patch adds descriptions for mt8195 IOMMU which also use ARM
Short-Descriptor translation table format.
In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
output), the other is for vpp(video processing pipe). They connects
with different smi-larbs, then some
This patchset adds MT8195 and MT8186 iommu support.
MT8195 have 3 IOMMU HWs. 2 IOMMU HW is for multimedia, and 1 IOMMU HW is
for infra-master, like PCIe/USB.
About the 2 MM IOMMU HW, something like this:
IOMMU(VDO) IOMMU(VPP)
| |
From: Sven Peter
The M1 Pro/Max/Ultra SoCs come with a new variant of DART which
supports a larger physical address space with a different PTE format.
Pass through the correct paddr address space size and the PTE format
to the io-pgtable code which will take care of the rest.
Signed-off-by:
From: Sven Peter
The M1 Max/Pro SoCs come with a new DART variant that is incompatible with
the previous one. Add a new compatible for those.
Signed-off-by: Sven Peter
Acked-by: Rob Herring
---
v2 changes:
- added Rob's Acked-by:
---
Documentation/devicetree/bindings/iommu/apple,dart.yaml
Hej,
I've taken over this series to add support for DART on M1 Pro/Max from
Sven.
Since v1 we have discovered further differences in the PTE format. It
has four differences which makes it incompatible with the one in the
M1:
- the physical addresses are shifted left by 4 bits and and have 2
From: Sven Peter
The DARTs present in the M1 Pro/Max/Ultra SoC use a diffent PTE format.
They support a 42bit physical address space by shifting the paddr and
extending its mask inside the PTE.
PTE flags are incompatible with iopte_type() since BIT(1) in the PTE
tags "uncached" mappings.
They
From: Sven Peter
DART allows to only expose a subpage to the device. While this is an
optional feature on the M1 DARTs the new ones present on the Pro/Max
models require this field in every PTE.
Signed-off-by: Sven Peter
---
drivers/iommu/io-pgtable-arm.c | 10 ++
1 file changed, 10
82 matches
Mail list logo
