On 07/13, Vivek Gautam wrote: > Hi Stephen, > > > On 07/13/2017 04:24 AM, Stephen Boyd wrote: > >On 07/06, Vivek Gautam wrote: > >>@@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain > >>*domain, unsigned long iova, > >> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long > >> iova, > >> size_t size) > >> { > >>- struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; > >>+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > >>+ struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; > >>+ size_t ret; > >> if (!ops) > >> return 0; > >>- return ops->unmap(ops, iova, size); > >>+ pm_runtime_get_sync(smmu_domain->smmu->dev); > >Can these map/unmap ops be called from an atomic context? I seem > >to recall that being a problem before. > > That's something which was dropped in the following patch merged in master: > 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock > > Looks like we don't need locks here anymore? >
While removing the spinlock around the map/unmap path may be one thing, I'm not sure that's all of them. Is there a path from an atomic DMA allocation (GFP_ATOMIC sort of thing) mapped into an IOMMU for a device that can eventually get down to here and attempt to turn a clk on? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu