- 18 May, 2020 2 commits
-
-
Sibi Sankar authored
The modem remote processor has two access paths to DDR. One path is directly connected to DDR and another path goes through an SMMU. The SMMU path is configured to be a direct mapping because it's used by various peripherals in the modem subsystem. Typically this direct mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor Execution Environment) before the kernel is entered. In certain firmware configuration, especially when the kernel is already in full control of the SMMU, defer programming the modem SIDs to the kernel. Let's add compatibles here so that we can have the kernel program the SIDs for the modem in these cases. Signed-off-by:
Sibi Sankar <sibis@codeaurora.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200511175532.25874-1-sibis@codeaurora.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
Chen Zhou authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/iommu/arm-smmu-v3.c:2989:26: warning: variable ‘smmu’ set but not used [-Wunused-but-set-variable] struct arm_smmu_device *smmu; Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Link: https://lore.kernel.org/r/20200508014955.87630-1-chenzhou10@huawei.comSigned-off-by:
-
- 07 May, 2020 7 commits
-
-
Andre Przywara authored
The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with arm,smmu-v1, even though the MMU-400 is compatible as well. Allow this combination as well to let the Arm Juno board pass the test. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20200507112430.183940-2-andre.przywara@arm.comSigned-off-by:
-
Sibi Sankar authored
Add iommus property to remoteproc modem node. Following SMMU global faults are seen without it. arm-smmu 15000000.iommu: Unexpected global fault, this could be serious arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000 arm-smmu 15000000.iommu: Unexpected global fault, this could be serious arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000461, GFSYNR2 0x00000000 Signed-off-by:Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/r/38c607841e81664a2db69a27260cd7dfbd653458.1587407458.git.saiprakash.ranjan@codeaurora.orgSigned-off-by:
-
Sibi Sankar authored
Add iommus property to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/561e9b42b8665fc9712fdb40a525ab8871fcbdac.1587407458.git.saiprakash.ranjan@codeaurora.orgSigned-off-by:
-
Jordan Crouse authored
Some client devices want to directly map the IOMMU themselves instead of using the DMA domain. Allow those devices to opt in to direct mapping by way of a list of compatible strings. Co-developed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Sai Prakash Ranjan authored
Implement the new def_domain_type call-back for the ARM SMMU driver. We need this to support requesting the domain type by the client devices. Signed-off-by:
-
Sai Prakash Ranjan authored
Currently the QCOM specific smmu reset implementation is very specific to SDM845 SoC and has a wait-for-safe logic which may not be required for other SoCs. So move the SDM845 specific logic to its specific reset function. Also add SC7180 SMMU compatible for calling into QCOM specific implementation. Signed-off-by:
-
Sai Prakash Ranjan authored
Currently on reboot/shutdown, the following messages are displayed on the console as error messages before the system reboots/shutdown as part of remove callback. On SC7180: arm-smmu 15000000.iommu: removing device with active domains! arm-smmu 5040000.iommu: removing device with active domains! Make this error message more informative and less scary. Reported-by:
Douglas Anderson <dianders@chromium.org> Suggested-by:
-
- 05 May, 2020 31 commits
-
-
Joerg Roedel authored
The function is now only used in IOMMU core code and shouldn't be used outside of it anyway, so remove the export for it. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
-
Joerg Roedel authored
Move the calls to dev_iommu_get() and try_module_get() into __iommu_probe_device(), so that the callers don't have to do it on their own. Signed-off-by:
-
Joerg Roedel authored
All drivers are converted to use the probe/release_device() call-backs, so the add_device/remove_device() pointers are unused and the code using them can be removed. Signed-off-by:
-
Joerg Roedel authored
Convert the Exynos IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
On Exynos platforms there can be more than one SYSMMU (IOMMU) for one DMA master device. Since the IOMMU core code expects only one hardware IOMMU, use the first SYSMMU in the list. Signed-off-by:
-
Joerg Roedel authored
Convert the OMAP IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Remove the tracking of device which could not be probed because their IOMMU is not probed yet. Replace it with a call to bus_iommu_probe() when a new IOMMU is probed. Signed-off-by:
-
Joerg Roedel authored
Convert the Renesas IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the Tegra IOMMU drivers to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the Rockchip IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the QCOM IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the Mediatek-v1 IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the Mediatek IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the MSM IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the VirtIO IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the S390 IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the PAMU IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the arm-smmu and arm-smmu-v3 drivers to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Convert the Intel IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20200429133712.31431-17-joro@8bytes.orgSigned-off-by:
-
Joerg Roedel authored
Convert the AMD IOMMU Driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by:
-
Joerg Roedel authored
Make use of generic IOMMU infrastructure to gather the same information carried in dev_data->passthrough and remove the struct member. Signed-off-by:
-
Joerg Roedel authored
Add a check to the bus_iommu_probe() call-path to make sure it ignores devices which have already been successfully probed. Then export the bus_iommu_probe() function so it can be used by IOMMU drivers. Signed-off-by:
-
Joerg Roedel authored
After the previous changes the iommu group may not have a default domain when iommu_group_add_device() is called. With no default domain iommu_group_create_direct_mappings() will do nothing and no direct mappings will be created. Rename iommu_group_create_direct_mappings() to iommu_create_device_direct_mappings() to better reflect that the function creates direct mappings only for one device and not for all devices in the group. Then move the call to the places where a default domain actually exists. Signed-off-by:
-
Joerg Roedel authored
When a bus is initialized with iommu-ops, all devices on the bus are scanned and iommu-groups are allocated for them, and each groups will also get a default domain allocated. Until now this happened as soon as the group was created and the first device added to it. When other devices with different default domain requirements were added to the group later on, the default domain was re-allocated, if possible. This resulted in some back and forth and unnecessary allocations, so change the flow to defer default domain allocation until all devices have been added to their respective IOMMU groups. The default domains are allocated for newly allocated groups after each device on the bus is handled and was probed by the IOMMU driver. Signed-off-by:
-
Joerg Roedel authored
This makes it easier to remove to old code-path when all drivers are converted. As a side effect that it also fixes the error cleanup path. Signed-off-by:
-
Joerg Roedel authored
This is needed to defer default_domain allocation for new IOMMU groups until all devices have been added to the group. Signed-off-by:
-
Joerg Roedel authored
Well, not really. The call to iommu_alloc_default_domain() in iommu_group_get_for_dev() has to stay around as long as there are IOMMU drivers using the add/remove_device() call-backs instead of probe/release_device(). Those drivers expect that iommu_group_get_for_dev() returns the device attached to a group and the group set up with a default domain (and the device attached to the groups current domain). But when all drivers are converted this compatability mess can be removed. Signed-off-by:
-
Joerg Roedel authored
Add call-backs to 'struct iommu_ops' as an alternative to the add_device() and remove_device() call-backs, which will be removed when all drivers are converted. The new call-backs will not setup IOMMU groups and domains anymore, so also add a probe_finalize() call-back where the IOMMU driver can do per-device setup work which require the device to be set up with a group and a domain. Signed-off-by:
-
Joerg Roedel authored
When check_device() fails on the device, it is not handled by the IOMMU and amd_iommu_add_device() needs to return -ENODEV. Signed-off-by:
-
Joerg Roedel authored
The check was only needed for the DMA-API implementation in the AMD IOMMU driver, which no longer exists. Signed-off-by:
-
Joerg Roedel authored
The Intel VT-d driver already has a matching function to determine the default domain type for a device. Wire it up in intel_iommu_ops. Signed-off-by:
-
