On Mon, Nov 16, 2020 at 7:59 AM Thierry Reding <thierry.red...@gmail.com> wrote: > > On Fri, Nov 06, 2020 at 04:27:10AM +0000, John Stultz wrote: > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index 04878caf6da49..c64d7a2b65134 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > > @@ -248,6 +248,7 @@ config SPAPR_TCE_IOMMU > > config ARM_SMMU > > tristate "ARM Ltd. System MMU (SMMU) Support" > > depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) > > + depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y > > select IOMMU_API > > select IOMMU_IO_PGTABLE_LPAE > > select ARM_DMA_USE_IOMMU if ARM > > This, in conjunction with deferred probe timeout, causes mayhem on > Tegra186. The problem, as far as I can tell, is that there are various > devices that are hooked up to the ARM SMMU, but if ARM SMMU ends up > being built as a loadable module, then those devices will initialize > without IOMMU support (because deferred probe will timeout before the > ARM SMMU module can be loaded from the root filesystem). > > Unfortunately, the ARM SMMU module will eventually end up being loaded > once the root filesystem has been mounted (for example via SDHCI or > Ethernet, both with using just plain, non-IOMMU-backed DMA API) and then > initialize, configuring as "fault by default", which then results from a > slew of SMMU faults from all the devices that have previously configured > themselves without IOMMU support.
Oof. My apologies for the trouble. Thanks so much for the report. Out of curiosity, does booting with deferred_probe_timeout=30 avoid the issue for you? thanks -john _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
