> -----Original Message----- > From: iommu-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx [mailto:iommu- > bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Will Deacon > Sent: Tuesday, July 01, 2014 3:04 PM > To: Olav Haugan > Cc: linux-arm-msm@xxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; > thierry.reding@xxxxxxxxx; vgandhi@xxxxxxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [RFC/PATCH 2/7] iommu-api: Add map_range/unmap_range > functions > > Hi Olav, > > On Mon, Jun 30, 2014 at 05:51:51PM +0100, Olav Haugan wrote: > > Mapping and unmapping are more often than not in the critical path. > > map_range and unmap_range allows SMMU driver implementations to > > optimize the process of mapping and unmapping buffers into the SMMU > page tables. > > Instead of mapping one physical address, do TLB operation (expensive), > > mapping, do TLB operation, mapping, do TLB operation the driver can > > map a scatter-gatherlist of physically contiguous pages into one > > virtual address space and then at the end do one TLB operation. > > > > Additionally, the mapping operation would be faster in general since > > clients does not have to keep calling map API over and over again for > > each physically contiguous chunk of memory that needs to be mapped to > > a virtually contiguous region. > > I like the idea of this, although it does mean that drivers implementing > the range mapping functions need more featureful page-table manipulation > code than currently required. > > For example, iommu_map uses iommu_pgsize to guarantee that mappings are > created in blocks of the largest support page size. This can be used to > simplify iterating in the SMMU driver (although the ARM SMMU driver > doesn't yet make use of this, I think Varun would add this when he adds > support for sections). Yes, this would be supported. -Varun -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
